Component firmware-version for transceivers using OIF-CMIS or SFP-DD MIS
Closed this issue · 6 comments
For newer generation optical transceivers that comply to the OIF-CMIS or the SFP-DD MIS specifications, the firmware version is reported as two U8 values representing the major and minor revision. The top level component leaf used to report the firmware version is defined as a string.
leaf firmware-version {
type string;
description
"For hardware components, this is the version of associated
firmware that is running on the component, if applicable.";
}
Should this leaf be changed to a union of the existing string and the two uint8 values or should it remain a string and the description be updated to indicate how to present these two values in string format?
My current assumption is to convert each U8 into a decimal representation of the value, separate them with a dot and return a string.
I.E. A transceiver reporting Major Rev 0x12 and minor rev 0x05 should present the firmware-version leaf as "18.5" but its not clear from the description if this is correct.
@proberts2022 your proposal sounds appropriate to me. This leaf is not intended to be specific to an individual hardware component type so I don't think it would be appropriate to add / union the specification specific format here.
If some operational use case arises where a user wants leaf(s) which map 1:1 to the spec for this hardware, I think we could explore some other option such as a component specific firmware version like
/components/component/transceiver/cmis/firmware-version. But before going down that route, I'd like to hear what the operational use case(s) are.
I'd like to hear what the operational use case(s) are.
b/314350074 :-)
I'd like to hear what the operational use case(s) are.
b/314350074 :-)
Hah hah! Here is the open source functional test for this:
It currently does not have any specific expectations for the version format, other than it must be some string. So for at least this use case, there's currently no constraint on the format of that string.
@dplore
Sorry but I do not understand the reference to "b/314350074" but my use case is is in fact the ZR digital coherent optics that fall into this category of OIF-CMIS transceivers (at least of QSFP56-DD versions).
I think the descriptive text for the components:component:firmware-version be updated to explain how to deal with this case
Something like: "For transceivers using OIF-CMIS or SFP-DD MIS, where the firmware version is reported as two unit8 values, these values should be converted into printable numeric representation with a decimal separator for reporting in this leaf. For example, a transceiver reporting major revision 0x12 and minor revision 0x05 should present the firmware-version leaf as the string 18.5"
Hi @proberts2022 , please ignore the b/314350074 reference and instead refer to the OpenConfig featureprofiles test for transceiver firmware version streaming checks .
This test serves as the source of truth for the detailed expectation of how firmware versions should be reported for at least ZR type transceivers. We (the test authors) do not have an operational requirement to constrain the firmware version string format at this time. @ahsaanyousaf (transceiver firmware test author) in case you have any comments.
The issue with updating the yang description is that this leaf represents the firmware version of every possible type of component that might ever be present in a network device. At the moment, a plain, unstructured string meets the operational use cases. Prescribing expected string formats, parsing and transformations in the textual description of the leaf would not scale I think.
If a network operator has an operational need for more structure on firmware versions, they are welcome to make the case and propose changes to the above code and/or propose new models to add some structure that would scale.
Closing this issue. If someone has an operational use case that the string formatted data type cannot meet, feel free to reopen.