openBackhaul / equipment

Equipment for an Ethernet PHY interface according to IEEE 802.3
Apache License 2.0
1 stars 0 forks source link

Empty occupying-fru - WireEquipment #10

Closed pawelk88 closed 1 year ago

pawelk88 commented 4 years ago

It is possible to have holder with occupying-fru empty? In case when we always create Equipment related to Holder then I think it shouldn't be possible to have empty this relation.

In my opinion it should be always fill by UUID of Equipment.

demx8as6 commented 3 years ago

It is possible to have holder with occupying-fru empty?

The answer is written in the TrasnmitterEquipment document (add reference)

[...] Holder as well as associated Equipment shall be automatically instantiated as soon as the ExpectedEquipment in the overlying level of the hierarchy got instantiated. Every existing Holder instance shall always be referencing an Equipment instance (the _occupyingFru attribute at the Holder object shall always contain the UUID of an Equipment object that waits to be detailed with ExpectedEquipment and ActualEquipment objects) [...]

In short: each holder object should have an parameter pointing to an equipment object. - answer: no.

--

In my opinion it should be always fill by UUID of Equipment. [sko] correct!

Action item: As consequence the CoreModel should be refactored (pruning and refactoring) to make the leaf occupying-fru mandatory and to update the description.

demx8as6 commented 3 years ago

result in YANG should be:

[...] grouping holder { leaf occupying-fru { mandatory "true" type leafref { path "/core-model:control-construct/core-model:equipment/core-model:uuid"; } description "The FRU that is occupying the holder. A holder may be unoccupied in reality, but always an abstract equipment object exists. An FRU may occupy more hat one holder (using or blocking are intentionally not distinguished here)."; } [...]

PrathibaJee commented 2 years ago

The attribute occupying-fru is in the CoreModel. So, changes will be covered in the CoreMode issue#30

demx8as6 commented 1 year ago

Proposal to the 5G-xhaul call on 19th of October 2022: This issue should be closed without further activity once CoreModel #30 is approved.