MCO-1748: Proposed updates to MCN in 4.20 for Image Mode Status Reporting
#1809
Conversation
|
@isabella-janssen: This pull request references MCO-1748 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
@isabella-janssen: This pull request references MCO-1748 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
isabella-janssen
force-pushed
the
ocl-status-reporting
branch
from
5f153cc to
12f96ab
Compare
|
|
||
| The desired config found in the spec will get updated immediately when a new config is found on the node. However, the desired config found in the status will only get updated once the new config has been validated in the machine config daemon. In the current implementation, the desired config is populated in the status by checking whether the update successfully gets past the "UpdatePrepared" phase. If the "UpdatePrepared" phase succeeds, then the status can safely add the desired config. | ||
| <!-- TODO: check on the "the image has been successfully created" condition for the deire image being in the status --> | ||
| The desired config or image found in `Spec` will get updated immediately when a new config or image is found on the node. However, the desired config and image found in `Status` will only get updated once the new config has been validated in the MCD or the image has been successfully created. In the current implementation, the desired config is populated in the status by checking whether the update successfully gets past the "UpdatePrepared" phase. If the "UpdatePrepared" phase succeeds, then the status can safely add the desired config. |
There was a problem hiding this comment.
Question to Reviewer
A standard update flow should progress as follows:
- Create rendered MC
- Update desired config value in MCN's
Spec - Validate new rendered MC
- Update desired config value in MCN's
Status
My question is whether OCL has a similar "validation" step after setting the machineconfiguration.openshift.io/desiredImage annotation on the node and before the update to that value can occur? If not, does it make sense to have a desired image set in Spec?
There was a problem hiding this comment.
To clarify the question, are you asking if we validate the current state of the node on the previous config? Or whether we validate the incoming desiredImage to see if it's valid or not?
There was a problem hiding this comment.
The latter, whether we validate the incoming desiredImage to see if it's valid or not. My intent behind this question is to understand if there is some validation post setting the desired image annotation on the node and when the update can actually proceed, similar to how MCN has the reconcile and other checks before UpdatePrepared is flipped to True.
There was a problem hiding this comment.
Apologies for missing the follow-up, I think there isn't any validation, so any failures would come in the update process itself when we try to pull the image
There was a problem hiding this comment.
if im understanding your question, i dont know that there is a specific "validation". The node rollout when image mode is enabled is consistent with the legacy MCO rollout process
There was a problem hiding this comment.
Thanks @yuqi-zhang & @dkhater-redhat for the input! I've updated the enhancement to be reflective of what I envision the natural difference in desiredImage in Spec and Status would be:
- MCN.Spec.ConfigImage.DesiredImage = populated on
machineconfiguration.openshift.io/desiredImageannotation being set on node - MCN.Status.ConfigImage.DesiredImage = populated on successful start of node update (image successfully pulled/update to image started)
isabella-janssen
force-pushed
the
ocl-status-reporting
branch
4 times, most recently
from
9608341 to
fbbc56c
Compare
|
@isabella-janssen: This pull request references MCO-1748 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
There was a problem hiding this comment.
Note to reviewer
That the following console outputs are what I see as the possible MCN updates during an OCL update, but I would like reviews on the flow from someone with better knowledge of OCL to chime in.
There was a problem hiding this comment.
i think that makes sense. I think the most important things to monitor are current, desired, and osimages.
isabella-janssen
force-pushed
the
ocl-status-reporting
branch
from
6c33db1 to
b56df3e
Compare
|
@isabella-janssen: This pull request references MCO-1748 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
|
||
| The desired config found in the spec will get updated immediately when a new config is found on the node. However, the desired config found in the status will only get updated once the new config has been validated in the machine config daemon. In the current implementation, the desired config is populated in the status by checking whether the update successfully gets past the "UpdatePrepared" phase. If the "UpdatePrepared" phase succeeds, then the status can safely add the desired config. | ||
| <!-- TODO: check on the "the image has been successfully created" condition for the deire image being in the status --> | ||
| The desired config or image found in `Spec` will get updated immediately when a new config or image is found on the node. However, the desired config and image found in `Status` will only get updated once the new config has been validated in the MCD or the image has been successfully created. In the current implementation, the desired config is populated in the status by checking whether the update successfully gets past the "UpdatePrepared" phase. If the "UpdatePrepared" phase succeeds, then the status can safely add the desired config. |
There was a problem hiding this comment.
To clarify the question, are you asking if we validate the current state of the node on the previous config? Or whether we validate the incoming desiredImage to see if it's valid or not?
isabella-janssen
force-pushed
the
ocl-status-reporting
branch
from
a09bf4f to
38ac165
Compare
|
@isabella-janssen: This pull request references MCO-1748 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
isabella-janssen
force-pushed
the
ocl-status-reporting
branch
from
5a32f6b to
dfe00ab
Compare
|
@isabella-janssen: This pull request references MCO-1748 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Inactive enhancement proposals go stale after 28d of inactivity. See https://github.com/openshift/enhancements#life-cycle for details. Mark the proposal as fresh by commenting If this proposal is safe to close now please do so with /lifecycle stale |
openshift-merge-robot
added
the
needs-rebase
openshift-ci
bot
added
the
lifecycle/stale
isabella-janssen
force-pushed
the
ocl-status-reporting
branch
from
dfe00ab to
e39b4b0
Compare
openshift-merge-robot
removed
the
needs-rebase
|
/remove-lifecycle stale |
openshift-ci
bot
removed
the
lifecycle/stale
isabella-janssen
force-pushed
the
ocl-status-reporting
branch
from
e39b4b0 to
4c410ba
Compare
|
@isabella-janssen: This pull request references MCO-1748 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
|
||
| The desired config found in the spec will get updated immediately when a new config is found on the node. However, the desired config found in the status will only get updated once the new config has been validated in the machine config daemon. In the current implementation, the desired config is populated in the status by checking whether the update successfully gets past the "UpdatePrepared" phase. If the "UpdatePrepared" phase succeeds, then the status can safely add the desired config. | ||
| <!-- TODO: check on the "the image has been successfully created" condition for the deire image being in the status --> | ||
| The desired config or image found in `Spec` will get updated immediately when a new config or image is found on the node. However, the desired config and image found in `Status` will only get updated once the new config has been validated in the MCD or the image has been successfully created. In the current implementation, the desired config is populated in the status by checking whether the update successfully gets past the "UpdatePrepared" phase. If the "UpdatePrepared" phase succeeds, then the status can safely add the desired config. |
There was a problem hiding this comment.
Apologies for missing the follow-up, I think there isn't any validation, so any failures would come in the update process itself when we try to pull the image
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: yuqi-zhang 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 |
openshift-ci
bot
added
the
approved
isabella-janssen
changed the title
Status ReportingImage Mode Status Reporting
|
@isabella-janssen: This pull request references MCO-1748 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
isabella-janssen
force-pushed
the
ocl-status-reporting
branch
from
7705242 to
5d54b14
Compare
|
|
||
| The desired config found in the spec will get updated immediately when a new config is found on the node. However, the desired config found in the status will only get updated once the new config has been validated in the machine config daemon. In the current implementation, the desired config is populated in the status by checking whether the update successfully gets past the "UpdatePrepared" phase. If the "UpdatePrepared" phase succeeds, then the status can safely add the desired config. | ||
| <!-- TODO: check on the "the image has been successfully created" condition for the deire image being in the status --> | ||
| The desired config or image found in `Spec` will get updated immediately when a new config or image is found on the node. However, the desired config and image found in `Status` will only get updated once the new config has been validated in the MCD or the image has been successfully created. In the current implementation, the desired config is populated in the status by checking whether the update successfully gets past the "UpdatePrepared" phase. If the "UpdatePrepared" phase succeeds, then the status can safely add the desired config. |
There was a problem hiding this comment.
if im understanding your question, i dont know that there is a specific "validation". The node rollout when image mode is enabled is consistent with the legacy MCO rollout process
There was a problem hiding this comment.
i think that makes sense. I think the most important things to monitor are current, desired, and osimages.
Thanks for the review @dkhater-redhat! Yes, the API questions were ironed out on @naseerahkani's API PR (openshift/api#2383), so they should be fine. |
@yuqi-zhang Sorry I missed this question, I think this should be fine to approve/merge considering the API review was pretty comprehensive of what I would've expected to be conversations in this PR. But I'm open to merging this post API or MCO merge instead if that's preferred. |
…e 'image mode status reporting' in the MCO
isabella-janssen
force-pushed
the
ocl-status-reporting
branch
from
c026c61 to
3366f02
Compare
|
@isabella-janssen: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/lgtm We can always update as needed, thanks! |
This outlines the proposed changes to the MachineConfigNode (MCN) resource in 4.20 to finalize "Image Mode Status Reporting" in the MCO, which is defined in epic MCO-1506. The primary changes in this enhancement include: