MCO-1675: [API 2/6] Update API for Status Reporting needs #2383
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@naseerahkani: This pull request references MCO-1675 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. |
|
Hello @naseerahkani! Some important instructions when contributing to openshift/api: |
openshift-ci
bot
added
the
size/M
| // +kubebuilder:printcolumn:name="UpdatedOSImage",type="string",JSONPath=.status.conditions[?(@.type=="AppliedOSImage")].status,priority=1 | ||
| // +kubebuilder:printcolumn:name="UpdatedFiles",type="string",JSONPath=.status.conditions[?(@.type=="AppliedFiles")].status,priority=1 |
There was a problem hiding this comment.
I'd imagine these and the ImagePulledFromRegistry column would somehow need to be feature gated since they will not be conditions populated in a non-tech preview cluster.
There was a problem hiding this comment.
I don't believe there exists today a way for us to feature-gate print columns - although this is something we could add if we had enough of a use case for it.
What is the worst case here if the conditions don't exist here? Does it show up empty? Does it result in a failure to display the results from a command?
There was a problem hiding this comment.
although this is something we could add if we had enough of a use case for it.
Maybe adding this as a low priority backlog item would be good, but I don't think the use case for it here is important enough.
What is the worst case here if the conditions don't exist here? Does it show up empty? Does it result in a failure to display the results from a command?
It shows up empty, which is not the end of the world. I just don't think it's ideal if there's another approach, but it seems that there is not really another option here.
There was a problem hiding this comment.
These columns will not be printed for the time being to make sure users are not confused. They will be added back when the image mode status reporting is ready to be GAed. The status of this will be tracked in this ticket.
| // Deprecated: AppliedFilesAndOS is being replaced by AppliedFiles and AppliedOSImage. | ||
| // This constant is maintained for backward compatibility. | ||
| MachineConfigNodeAppliedFilesAndOS StateProgress = "AppliedFilesAndOS" |
There was a problem hiding this comment.
I'm not quite sure how we want to handle this, but I'm curious if this approach is valid. This is how I'm interpreting this, but I could be incorrect:
- This merging would state that in 4.20 the
MachineConfigNodeAppliedFilesAndOSstatus is depreciated in general (so in both tech preview and non-tech preview clusters). - But, this isn't quite correct since a standard non-tech preview enabled cluster in 4.20 does have a supported
MachineConfigNodeAppliedFilesAndOScondition. - Maybe a feature gate here can distinguish that the idea is to deprecate this starting with the implementation of
ImageModeStatusReporting? Or maybe wait until the new statuses (MachineConfigNodeUpdateFiles&MachineConfigNodeUpdateOS) are implemented before it makes sense to start a deprecation ofMachineConfigNodeAppliedFilesAndOS(maybe that's done in a subsequent release?)?
This is probably something that would need input from other MCO/API folks. I'm sure there's a set process for this, but I'm not aware of it.
There was a problem hiding this comment.
Marking this type deprecated would only show up for those consuming this as a Go package as these comments won't show up in generated documentation that end-users of OpenShift would see.
That being said, I think it is generally a bit of an anti-pattern to deprecate something before there is a concrete replacement for it. In this case if it is only deprecated in TPNU clusters I would wait to mark this as deprecated until the feature that deprecates it goes GA.
Also note that deprecating something doesn't mean it stops functioning, just that users should be aware that this condition will be removed in a future release and should consider relying on other conditions instead. IIUC, this condition should continue to be populated the same as it always has.
There was a problem hiding this comment.
This type still needs to be deprecated and will be taken care of at another time. For future reference, this ticket will be used to keep track of changes/updates.
openshift-ci
bot
added
size/XXL
|
/retest-required |
| // +kubebuilder:printcolumn:name="UpdatedOSImage",type="string",JSONPath=.status.conditions[?(@.type=="AppliedOSImage")].status,priority=1 | ||
| // +kubebuilder:printcolumn:name="UpdatedFiles",type="string",JSONPath=.status.conditions[?(@.type=="AppliedFiles")].status,priority=1 |
There was a problem hiding this comment.
I don't believe there exists today a way for us to feature-gate print columns - although this is something we could add if we had enough of a use case for it.
What is the worst case here if the conditions don't exist here? Does it show up empty? Does it result in a failure to display the results from a command?
| // Deprecated: AppliedFilesAndOS is being replaced by AppliedFiles and AppliedOSImage. | ||
| // This constant is maintained for backward compatibility. | ||
| MachineConfigNodeAppliedFilesAndOS StateProgress = "AppliedFilesAndOS" |
There was a problem hiding this comment.
Marking this type deprecated would only show up for those consuming this as a Go package as these comments won't show up in generated documentation that end-users of OpenShift would see.
That being said, I think it is generally a bit of an anti-pattern to deprecate something before there is a concrete replacement for it. In this case if it is only deprecated in TPNU clusters I would wait to mark this as deprecated until the feature that deprecates it goes GA.
Also note that deprecating something doesn't mean it stops functioning, just that users should be aware that this condition will be removed in a future release and should consider relying on other conditions instead. IIUC, this condition should continue to be populated the same as it always has.
|
/lgtm |
openshift-ci
bot
added
lgtm
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: everettraven, JoelSpeed, naseerahkani, 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 |
|
/retest-required |
|
/override ci/prow/e2e-aws-ovn-hypershift-conformance Test failure on a DNS test, don't believe this is related |
|
@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/e2e-aws-ovn-hypershift-conformance 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 kubernetes-sigs/prow repository. |
|
/hold Revision 9439983 was retested 3 times: holding |
openshift-ci
bot
added
the
do-not-merge/hold
|
/hold cancel |
openshift-ci
bot
removed
the
do-not-merge/hold
|
@naseerahkani: The following tests failed, say
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. |
|
/close Closing in favor of #2442, which contains all the commits from this PR, an additional commit to pull in the changes from https://github.com/openshift/api/tree/master, and a small tweak for new validation standards. |
openshift-merge-robot
added
the
needs-rebase
|
PR needs rebase. 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. |
|
@isabella-janssen: Closed this PR. 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 kubernetes-sigs/prow repository. |
Updating the MachineConfigNode (MCN) object to support on cluster layering (OCL). Advice/suggestions for the comments for the updated code would be greatly appreciated.
Here are details on the enhancement.