platform: add fault description leaf and ACTION_FW_REPROGRAM#1455
platform: add fault description leaf and ACTION_FW_REPROGRAM#1455brianneville wants to merge 8 commits into
Conversation
Add an identity to represent the case where the network operator should reprogram FPGA images and reload drivers in an effort to remediate a fault
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request extends the platform fault reporting model by introducing a new, explicit remediation action. This enhancement allows for better communication and automation of fault resolution by providing a standardized way to indicate when firmware reprogramming and driver reloading are necessary to address a fault, ensuring backward compatibility with existing implementations. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request adds a new ACTION_FW_REPROGRAM identity to the openconfig-platform-healthz-fault YANG model. The change is backward-compatible and follows the existing structure. I have one suggestion to improve the clarity of the new identity's description to avoid potential ambiguity for implementers.
a7b4c31 to
104aa6d
Compare
|
@mrevang for comment |
|
/gcbrun |
|
No major YANG version changes in commit a3337db |
|
Added to review for May 12, 2026 OC Operators meeting |
| "This model defines device reported fault"; | ||
|
|
||
| oc-ext:openconfig-version "0.1.0"; | ||
| oc-ext:openconfig-version "0.1.1"; |
There was a problem hiding this comment.
Since we are adding yang, this should be a minor version increment per semver rules
| oc-ext:openconfig-version "0.1.1"; | |
| oc-ext:openconfig-version "0.2.0"; |
dplore
left a comment
There was a problem hiding this comment.
@earies @rgwilton @nokia1adam do your implementations have a similar function ?
| The targeted component may need to be powercycled | ||
| for the reprogramming to take effect. |
There was a problem hiding this comment.
Recommend updating to say something like:
if a power cycle is required, then ACTION_POWER_CYCLE will also be set as a remediations/remediation/action.
| In comparison to ACTION_FACTORY_RESET action, | ||
| ACTION_FW_REPROGRAM does not necessarily involve resetting | ||
| the firmware back to its factory default. It also does not | ||
| involve resetting any certificates on disk or removing | ||
| any config files or OS images. |
There was a problem hiding this comment.
can you elaborate on where the firmware is stored? Is this reloading firmware stored in the device filesystem? In particular are there any other actions that may need to be performed for ACTION_FW_REPROGRAM ?
Change Scope
ACTION_FW_REPROGRAMto represent the case where the network operator should reprogram a component.descriptionleaf at/components/component/healthz/faults/fault/remediations/remediation/state/descriptionto allow vendors to provide more platform specific information about a particular remediating action.Platform Implementations
Tree View
This change adds the
descriptionleaf at: