Component upgrade state.#1242
Conversation
Update duration to secs. Add an Abort status.
|
Are there other use cases (in addition to transceiver FW upgrades)? |
|
@LimeHat I was thinking this could apply well to generic OS installs in which we don't have this information elsewhere either (and our workflows are still retrieving it via CLI). If folks would prefer to scope this down, my main need is around firmware upgrades on transceivers though, so that would be okay for me. |
|
step-percent-complete vs total-percent-complete --> The number of steps involved in a component upgrade is not standard between components/vendors. Is there any advantage in having this represented as two different parameters ? |
|
The number of steps utilized by a given implementation should not matter. "step-percent-complete" just represents the percent complete of the in-progress step as defined by the "step" leaf. When a new "step" starts this just gets reset to 0, so it wouldn't matter if there were 2 or 10 steps. |
|
/gcbrun |
|
No major YANG version changes in commit 8b509e9 |
|
About the 'step' leaf: The TransceiverFirmwareInstall service proposed in #293 has an RPC called Transfer and an RPC called Install. Are those what you mean by a 'step'? Would a router report a step called 'Transfer' and then a step called 'Install'? |
|
How does 'step' interact with the different identities of 'status'? For example we have a status called INSTALL_FILE_LOADING and another status called INSTALL_IN_PROGRESS as two separate status values. Those almost feel like they could be 2 different steps during a firmware upgrade. |
| "The component reboots due to critical errors."; | ||
| } | ||
|
|
||
| identity OPENCONFIG_INSTALL_STATUS { |
There was a problem hiding this comment.
What is the expected status when a device (e.g. router) first boots up and there hasn't been any firmware install on a transceiver? Suppress the install status leaf (i.e. don't return it)? Or do we need some sort of INSTALL_IDLE status?
| "The file is being loaded on the component."; | ||
| } | ||
|
|
||
| identity INSTALL_IN_PROGRESS { |
There was a problem hiding this comment.
There can be 3 separate steps in an overall install:
- transfer
- activate (with the option to not commit)
- commit
Do we consider the state to be INSTALL_IN_PROGRESS from when step 1 starts until the new firmware is committed? In other words, if an operator does an activate with the "no commit" option, and then operates the optic for several hours/days without committing the newly active bank, then the install status will stay as IN_PROGRESS during those hours/days until the bank containing the new firmware is finally committed? Note that the user could switch banks multiple times before finally deciding to commit the bank containing the new firmware. And they might decide to never commit the new firmware (may instead start a new install on top of it without ever comitting it).
| "The timestamp when the install started."; | ||
| } | ||
|
|
||
| leaf duration { |
There was a problem hiding this comment.
It feels like there is some overlap/duplication in having a start-timestamp, stop-timestamp, and duration. And would duration constantly update every second? (i.e. be very noisy if subscriber to ON_CHANGE)? I'd propose we drop the duration leaf here.
| description | ||
| "The percent complete for the in-progress step."; | ||
| } | ||
|
|
There was a problem hiding this comment.
The most value for % complete, start-timestamp and end-timestamp is for the transfer step. And it isn't so clear that it is realistic (or important) to know the % complete for activate, commit or abort. I'd suggest we rework this to have transfer-start-time, transfer-end-time, and transfer-percent-complete.
|
Discussed in the OC Operators Meeting Jan 6th 2026: I see some merge conflicts, as well as some unresolved comments, can we address those and then re-raise for discussion? |
ElodinLaarz
moved this from Ready to discuss
to Waiting for author
in OC Operator Review
7 participants
Related to #1241, this is a proposal to add upgrade state information for components.
Example output:
module: openconfig-platform
+--rw components
+--rw component* [name]
+--rw name -> ../config/name
+--ro state
| +--ro name? string
<......>
| +--ro upgrade
| +--ro new-version? string
| +--ro new-version-service-impacting? boolean
| +--ro status? identityref
| +--ro step? string
| +--ro step-percent-complete? oc-types:percentage
| +--ro total-percent-complete? oc-types:percentage
| +--ro start-timestamp? oc-types:timeticks64
| +--ro duration? yang:counter64
| +--ro stop-timestamp? oc-types:timeticks64
| +--ro last-known-failure? string
@robshakir @ahsaanyousaf could you please take a look?