-
Notifications
You must be signed in to change notification settings - Fork 254
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.
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
✨ Add reference to HostUpdatePolicy in Servicing with HFS Support #2041
Conversation
/assign @zaneb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking pretty solid.
Signed-off-by: Dmitry Tantsur <dtantsur@protonmail.com>
Servicing only runs when a host is powered off (either completely or by rebooting it). Signed-off-by: Dmitry Tantsur <dtantsur@protonmail.com>
Signed-off-by: Jacob Anders <janders@redhat.com> Removed unused ServicingData fields.
…ageHostPower. Signed-off-by: Jacob Anders <janders@redhat.com>
Signed-off-by: Jacob Anders <janders@redhat.com>
Signed-off-by: Jacob Anders <janders@redhat.com>
I've tested the code trying to update a firmware setting, it works updating the setting but the OperationalStatus for the BMH stays @zaneb @dtantsur any thoughts on this? Seems to be related to the comment's I've addressed in the last commit, but no idea at the moment. |
- we no longer need the currentError stored, since we don't clear the ErrorType before calling Service. - include dirty when changing the Status.Provisioning.Firmware, this is to ensure we would run an actionUpdate. - return actionUpdate if provisioner returns a clean result, but there are changes to the BMH. - acquireHostUpdatePolicy is also called during registerHost Signed-off-by: Iury Gregory Melo Ferreira <imelofer@redhat.com>
Moved back to the old logic, since for the |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: zaneb The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
What this PR does / why we need it:
This PR enables BMO to run Ironic servicing operations (such as applying firmware settings changes - or in the future firmware updates to already provisioned nodes). Servicing is an opt-in feature and is controlled by creation of a HostUpdatePolicy for a node with attributes indicating the desire to make changes to firmware configuration onReboot.
This is a partial implementation of metal3-io/metal3-docs@e260d42 (please note only firmware settings changes are currently supported, firmware update support will be added next).