Component upgrade state.

[ejbrever]

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?

[LimeHat]

Are there other use cases (in addition to transceiver FW upgrades)?
If not, shall we consider placement of this grouping in /components/component/transceiver (or introduce a new when condition based on the component type)?

[ejbrever]

@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.

[gprasat]

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 ?

[ejbrever]

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.