-
Notifications
You must be signed in to change notification settings - Fork 584
config/v1/types_cluster_version: Add Architecture to DesiredUpdate #1339
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
|
|
@@ -45,8 +45,17 @@ type ClusterVersionSpec struct { | |||||||
| // the current version does not match the desired version). The set of | ||||||||
| // recommended update values is listed as part of available updates in | ||||||||
| // status, and setting values outside that range may cause the upgrade | ||||||||
| // to fail. You may specify the version field without setting image if | ||||||||
| // an update exists with that version in the availableUpdates or history. | ||||||||
| // to fail. | ||||||||
| // | ||||||||
| // Some of the fields are inter-related with restrictions and meanings described here. | ||||||||
| // 1. image is specified, version is specified, architecture is specified. API validation error. | ||||||||
| // 2. image is specified, version is specified, architecture is not specified. You should not do this. version is silently ignored and image is used. | ||||||||
| // 3. image is specified, version is not specified, architecture is specified. API validation error. | ||||||||
| // 4. image is specified, version is not specified, architecture is not specified. image is used. | ||||||||
| // 5. image is not specified, version is specified, architecture is specified. version and desired architecture are used to select an image. | ||||||||
| // 6. image is not specified, version is specified, architecture is not specified. version and current architecture are used to select an image. | ||||||||
| // 7. image is not specified, version is not specified, architecture is specified. API validation error. | ||||||||
| // 8. image is not specified, version is not specified, architecture is not specified. API validation error. | ||||||||
| // | ||||||||
| // If an upgrade fails the operator will halt and report status | ||||||||
| // about the failing component. Setting the desired update value back to | ||||||||
|
|
@@ -191,7 +200,7 @@ type UpdateHistory struct { | |||||||
| // +nullable | ||||||||
| CompletionTime *metav1.Time `json:"completionTime"` | ||||||||
|
|
||||||||
| // version is a semantic versioning identifying the update version. If the | ||||||||
| // version is a semantic version identifying the update version. If the | ||||||||
| // requested image does not define a version, or if a failure occurs | ||||||||
| // retrieving the image, this value may be empty. | ||||||||
| // | ||||||||
|
|
@@ -224,6 +233,16 @@ type UpdateHistory struct { | |||||||
| // ClusterID is string RFC4122 uuid. | ||||||||
| type ClusterID string | ||||||||
|
|
||||||||
| // ClusterVersionArchitecture enumerates valid cluster architectures. | ||||||||
| // +kubebuilder:validation:Enum="Multi";"" | ||||||||
| type ClusterVersionArchitecture string | ||||||||
|
|
||||||||
| const ( | ||||||||
| // ClusterVersionArchitectureMulti identifies a multi architecture. A multi | ||||||||
| // architecture cluster is capable of running nodes with multiple architectures. | ||||||||
| ClusterVersionArchitectureMulti ClusterVersionArchitecture = "Multi" | ||||||||
| ) | ||||||||
|
|
||||||||
| // ClusterVersionCapability enumerates optional, core cluster components. | ||||||||
| // +kubebuilder:validation:Enum=openshift-samples;baremetal;marketplace;Console;Insights;Storage;CSISnapshot | ||||||||
| type ClusterVersionCapability string | ||||||||
|
|
@@ -406,17 +425,33 @@ type ComponentOverride struct { | |||||||
| type URL string | ||||||||
|
|
||||||||
| // Update represents an administrator update request. | ||||||||
| // +kubebuilder:validation:XValidation:rule="has(self.architecture) && has(self.image) ? (self.architecture == '' || self.image == '') : true",message="cannot set both Architecture and Image" | ||||||||
| // +kubebuilder:validation:XValidation:rule="has(self.architecture) && self.architecture != '' ? self.version != '' : true",message="Version must be set if Architecture is set" | ||||||||
| // +k8s:deepcopy-gen=true | ||||||||
| type Update struct { | ||||||||
| // version is a semantic versioning identifying the update version. When this | ||||||||
| // field is part of spec, version is optional if image is specified. | ||||||||
| // architecture is an optional field that indicates the desired | ||||||||
jottofar marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
| // value of the cluster architecture. In this context cluster | ||||||||
| // architecture means either a single architecture or a multi | ||||||||
| // architecture. architecture can only be set to Multi thereby | ||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So there's no way to transition back to the a single arch cluster? I wonder if we need to explicitly say, "on future updates, if the existing cluster image is multi architecture, then the downloaded image will also be multi architecture. There is no way to convert a cluster from multi to single architecture." I think I missed this while reviewing before but it seems odd that on future updates, having the field omitted/empty relies on the existing architecture
Thinking about this, which I got from trying to understand this API, that's not actually true is it, if I forced an image into the update that was single arch I could force the cluster back to single arch, is that ok?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That is right. Even if the current ask is only one time migration from single arch to multi arch , we do not want to add any more code to restrict the opposite. Officially we will only document that single to multi is supported. But there will be room for future change of scope. |
||||||||
| // only allowing updates from single to multi architecture. If | ||||||||
| // architecture is set, image cannot be set and version must be | ||||||||
| // set. | ||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: In other enums, we typically have a statement that says
Suggested change
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agree, will fix it.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed in 08f0ef0 |
||||||||
| // Valid values are 'Multi' and empty. | ||||||||
| // | ||||||||
| // +optional | ||||||||
| Architecture ClusterVersionArchitecture `json:"architecture"` | ||||||||
jottofar marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||
|
|
||||||||
| // version is a semantic version identifying the update version. | ||||||||
| // version is ignored if image is specified and required if | ||||||||
| // architecture is specified. | ||||||||
| // | ||||||||
| // +optional | ||||||||
| Version string `json:"version"` | ||||||||
|
|
||||||||
| // image is a container image location that contains the update. When this | ||||||||
| // field is part of spec, image is optional if version is specified and the | ||||||||
| // availableUpdates field contains a matching version. | ||||||||
| // image is a container image location that contains the update. | ||||||||
| // image should be used when the desired version does not exist in availableUpdates or history. | ||||||||
| // When image is set, version is ignored. When image is set, version should be empty. | ||||||||
| // When image is set, architecture cannot be specified. | ||||||||
| // | ||||||||
| // +optional | ||||||||
| Image string `json:"image"` | ||||||||
|
|
@@ -435,7 +470,7 @@ type Update struct { | |||||||
| // Release represents an OpenShift release image and associated metadata. | ||||||||
| // +k8s:deepcopy-gen=true | ||||||||
| type Release struct { | ||||||||
| // version is a semantic versioning identifying the update version. When this | ||||||||
| // version is a semantic version identifying the update version. When this | ||||||||
| // field is part of spec, version is optional if image is specified. | ||||||||
| // +required | ||||||||
| Version string `json:"version"` | ||||||||
|
|
||||||||
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.
Do any of the validations rely on a previously persisted state? If they don't, then we don't need separate update tests and the create validation should cover both cases
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.
Ok, I am going to remove this test.
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.
I had meant the entire set of onUpdate, none of them seem necessary since they all duplicate previous test cases IIUC. But I see now why you've got two different ones, it's the transitions from image to both and from architecture to both, makes sense, we should add an onCreate version though
Uh oh!
There was an error while loading. Please reload this page.
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.
Both onUpdate tests are covered by the following onCreate test, so unless I am missing something we do not need to add any new onCreate tests.
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.
We have onCreate
Should not allow image and architecture to be setwhich checks that both cannot be set so I'm not sure what can be added to onCreate to replicate the two onUpdates since each of them can start with only one of the values but the onCreate cannot (AFAIK).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.
And I originally added the
onUpdatetests to cover a user doing anoc patchfor example.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.
Also I can work on this even after the PR is merged. So lets not block the PR to get merged because of this.