Skip to content

Component upgrade state. #1242

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ejbrever wants to merge 11 commits into
base: master
Choose a base branch
from
Open

Component upgrade state. #1242

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
11 commits
Select commit Hold shift + click to select a range
8ac03af
Component upgrade state.
ejbrever Jan 3, 2025
50134ec
Make the version generic.
ejbrever Jan 3, 2025
7b9740d
Add missing oc- prefix.
ejbrever Jan 3, 2025
7c1b119
Merge branch 'master' into upgrades
ejbrever Jan 3, 2025
a0feab6
Update duration description.
ejbrever Jan 7, 2025
5055ae4
Add a units of seconds.
ejbrever Jan 7, 2025
15ac77f
s/upgrade/install to signify the new version may be higher or lower
ejbrever Jan 7, 2025
db91e09
Increment the YANG file version number.
ejbrever Jan 7, 2025
8b509e9
Merge branch 'master' into upgrades
dplore Feb 19, 2025
b003c71
Merge branch 'master' into upgrades
dplore Feb 19, 2025
c204ef2
Merge branch 'master' into upgrades
ejbrever Mar 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 41 additions & 1 deletion release/models/platform/openconfig-platform-types.yang
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,8 +22,13 @@ module openconfig-platform-types {
"This module defines data types (e.g., YANG identities)
to support the OpenConfig component inventory model.";

oc-ext:openconfig-version "1.9.0";
oc-ext:openconfig-version "1.10.0";

revision "2025-01-07" {
description
"Add OPENCONFIG_INSTALL_STATUS";
reference "1.10.0";
}

revision "2024-11-04" {
description
Expand Down Expand Up @@ -564,6 +569,41 @@ module openconfig-platform-types {
"The component reboots due to critical errors.";
}

identity OPENCONFIG_INSTALL_STATUS {

@jsterne jsterne Nov 4, 2025 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

description
"Base entity for component install status.";
}

identity INSTALL_FILE_LOADING {
base OPENCONFIG_INSTALL_STATUS;
description
"The file is being loaded on the component.";
}

identity INSTALL_IN_PROGRESS {

@jsterne jsterne Nov 4, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There can be 3 separate steps in an overall install:

  1. transfer
  2. activate (with the option to not commit)
  3. 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).

base OPENCONFIG_INSTALL_STATUS;
description
"The install is in-progress.";
}

identity INSTALL_COMPLETE {
base OPENCONFIG_INSTALL_STATUS;
description
"The install was completed.";
}

identity INSTALL_ABORT {
base OPENCONFIG_INSTALL_STATUS;
description
"The install was aborted.";
}

identity INSTALL_FAIL {
base OPENCONFIG_INSTALL_STATUS;
description
"The install failed.";
}

typedef component-redundant-role {
type enumeration {
enum PRIMARY {
Expand Down
85 changes: 84 additions & 1 deletion release/models/platform/openconfig-platform.yang
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,12 @@ module openconfig-platform {
(presence or absence of a component) and state (physical
attributes or status).";

oc-ext:openconfig-version "0.31.0";
oc-ext:openconfig-version "0.32.0";

revision "2025-03-14" {
description
"Add install state information.";
reference "0.32.0";

revision "2025-01-30" {
description
Expand Down Expand Up @@ -726,6 +731,83 @@ revision "2024-05-29" {

}

grouping platform-component-install-state {
description
"Install state data for platform components";

container install {
description
"Top-level container for component install state data";

leaf new-version {
type string;
description
"This is the version that is available on the component,
but the install is not complete or has not yet started.";
}

leaf new-version-service-impacting {
type boolean;
description
"A value of true indicates that installing would
be a service impacting event.";
}

leaf status {
type identityref {
base oc-platform-types:OPENCONFIG_INSTALL_STATUS;
}
description
"The status of the install.";
}

leaf step {
type string;
description
"Description of the current in-progress step of the install.";
}

leaf step-percent-complete {
type oc-types:percentage;
description
"The percent complete for the in-progress step.";
}

@jsterne jsterne Nov 18, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

leaf total-percent-complete {
type oc-types:percentage;
description
"The percent complete for the entire install process.";
}

leaf start-timestamp {
type oc-types:timeticks64;
description
"The timestamp when the install started.";
}

leaf duration {

@jsterne jsterne Nov 18, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

type oc-yang:counter64;
units "seconds";
description
"The time elapsed since the install was initiated or the
duration of the last install. This is reported in seconds.";
}

leaf stop-timestamp {
type oc-types:timeticks64;
description
"The timestamp when the install stopped.";
}

leaf last-known-failure {
type string;
description
"The reason of the last known failure, if the most recent
install ended in failure.";
}
}
}

grouping platform-component-temp-alarm-state {
description
"Temperature alarm data for platform components";
Expand Down Expand Up @@ -1330,6 +1412,7 @@ revision "2024-05-29" {
"'oc-platform-types:INTEGRATED_CIRCUIT' or " +
"'oc-platform-types:FRU'";
}
uses platform-component-install-state;
}

uses platform-component-properties-top;
Expand Down