Update ClusterVersion with a desired field and a history field#153
Conversation
openshift-ci-robot
added
the
size/M
openshift-ci-robot
added
the
approved
|
/assign @abhinavdahiya |
|
@deads2k as well |
| // This value may be empty during cluster startup, and then will be updated | ||
| // when a new update is being applied. Use the conditions array to know whether | ||
| // the update is complete. Only a limited amount of update history is preserved. | ||
| History []UpdateHistory `json:"history"` |
There was a problem hiding this comment.
document the ordering. Most recent to least recent or least recent to most recent
| CompletionTime *metav1.Time `json:"completionTime"` | ||
|
|
||
| // version is a semantic versioning identifying the update version. When this | ||
| // field is part of spec, version is optional if payload is specified. |
There was a problem hiding this comment.
I'd like to have an indication in the payload of what version it is. I don't think it should ever be optional here.
There was a problem hiding this comment.
It's optional if the payload doesn't have a version. Some payloads won't have a version. Also, the CVO may not know what the payload version is before it is requested (you can provide only an image and we have to honor it, and if you provide a false version we have to distinguish that as well).
In general, yes, we will have a version, but we need to be clear you can't always get one.
| // +optional | ||
| Version string `json:"version"` | ||
| // payload is a container image location that contains the update. When this | ||
| // field is part of spec, payload is optional if version is specified and the |
There was a problem hiding this comment.
even though it's not technically required, don't we always know this?
There was a problem hiding this comment.
It is possible for a release to not have a payload version defined (version must be a semantic version), or for us not to be able to retrieve the payload by image and thus get access to the version number (image -> version)
There was a problem hiding this comment.
Updated with the different godoc (payload is required on update history because a spec update that has version, no payload, and is missing availableUpdate would not result in an update history item).
|
If we have the information available, I'd like to always specify both version and payload. |
smarterclayton
force-pushed
the
update_cluster_version
branch
from
db1d49f to
3cd30b1
Compare
The current field is not useful because it doesn't represent level driven flows well. Instead, track the version the cluster is working towards as `status.desired` and each time that target changes update the `status.history` field. The `status.history` field allows us to know what previous updates were made and what times those completed. Even though rollback is not desirable, we need to report a field that indicates what the last successfully applied version was (user starts at 4.0.0, then upgrades to 4.0.1, which fails, then a new 4.0.2 version is released that also fails, we need to report 4.0.0 as the version to go back to).
smarterclayton
force-pushed
the
update_cluster_version
branch
from
3cd30b1 to
cae4137
Compare
|
The inability to pull makes sense so clients have to tolerate. /lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, smarterclayton The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
…sion openshift/api#153 moved the field for the current version as reported by the cluster version operator.
Fixing example command that extracts the current update image from the ClusterVersion object to match chnages to the api <openshift/api#153>
5 participants
The current field is not useful because it doesn't represent level
driven flows well. Instead, track the version the cluster is working
towards as
status.desiredand each time that target changes updatethe
status.historyfield. Thestatus.historyfield allows us toknow what previous updates were made and what times those completed.
Even though rollback is not desirable, we need to report a field that
indicates what the last successfully applied version was (user starts
at 4.0.0, then upgrades to 4.0.1, which fails, then a new 4.0.2
version is released that also fails, we need to report 4.0.0 as the
version to go back to).
Implemented in openshift/cluster-version-operator#63 and moved here to get final review.