Closed Nshet closed 1 month ago
the rationale for introducing slots i.e., the ability to model equipment holders in a chassis or a card (that supports daughter cards). This provides the ability for the operators to identify how many slots are occupied and which/how many are empty.
@aashaikh and @robshakir, any reasons why OpenConfig doesn't model the equipment slots?
openconfig-platform.yang
model.
We have discussed this topic in the working group a few times, but did not consider a 'slot' as something that would make sense as a system component. To enable this use case we added the empty
property as a base component state value: /components/component/state/empty
The empty leaf may be used by the device to indicate that a component position exists but is not populated. Using this flag, it is possible for the management system to learn how many positions are available (e.g., occupied vs. empty linecard slots in a chassis).
The usage model would be to have a chassis, for example, with multiple subcomponents of type linecard, where some linecard components are marked empty. The same concept would extend to daughtercards or ASICs that could be slotted in a parent linecard where the positions are not all yet populated.
We have so far not represented any capability type information in the data models, as the focus is on configuration and telemetry/inventory. The types of linecards that a chassis supports seems better suited for a data sheet (and devices do not generally support this type of interrogation AFAIK).
This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.
Just to curious to know about that, do you have any strategy of adding SLOT identity in the openconfig-platform-types yang under hardware component or if not does it sound good to introduce one by the vendor?