MCO-1443: Promote onclusterbuild to GA #2090

yuqi-zhang · 2024-11-07T23:56:32Z

Opened for testing. Based on guidance this is currently the first step: create new v1 API, gate remains off, v1 API is excluded from the image manifests

Also adds in: #2089

openshift-ci · 2024-11-07T23:56:35Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

openshift-ci · 2024-11-07T23:56:36Z

Hello @yuqi-zhang! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

openshift-ci · 2024-11-07T23:56:47Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: yuqi-zhang
Once this PR has been reviewed and has the lgtm label, please assign sjenning for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

yuqi-zhang · 2024-11-08T00:00:50Z

/test all

yuqi-zhang · 2024-11-08T18:05:26Z

/test all

First step to GA'ing the currently v1alpha1 APIs. Don't add to payload manifests yet, and the featuregate is retained.

openshift-ci-robot · 2024-11-08T22:26:14Z

@yuqi-zhang: This pull request references MCO-1443 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 task to target the "4.18.0" version, but no target version was set.

In response to this:

Opened for testing. Based on guidance this is currently the first step: create new v1 API, gate remains off, v1 API is excluded from the image manifests

Also adds in: #2089

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.

JoelSpeed

Can we take this promotion opportunity to go through the API thoroughly and improve validations and godocs please

JoelSpeed · 2024-11-09T13:45:33Z

...configuration/v1/tests/machineosbuilds.machineconfiguration.openshift.io/OnClusterBuild.yaml

@@ -0,0 +1,64 @@
+apiVersion: apiextensions.k8s.io/v1 # Hack because controller-gen complains if we don't have this
+name: "[TechPreview] MachineOSBuild"


No longer tech preview? I know it kind of is, but, we aren't likely to remember to update this when we update the gate, so this will become disjoint

JoelSpeed · 2024-11-09T13:46:01Z

...onfiguration/v1/tests/machineosconfigs.machineconfiguration.openshift.io/OnClusterBuild.yaml

@@ -0,0 +1,134 @@
+apiVersion: apiextensions.k8s.io/v1 # Hack because controller-gen complains if we don't have this
+name: "[TechPreview] MachineOSConfig"


No longer TP

JoelSpeed · 2024-11-09T13:50:04Z

machineconfiguration/v1/types_machineosbuild.go

+	// version tracks the newest MachineOSBuild for each MachineOSConfig
+	// +kubebuilder:validation:Minimum=1
+	// +kubebuilder:validation:Required
+	Version int64 `json:"version"`


I'm not following how this interoperates, in particular, with ConfigGeneration? Can you remind me?

I think the original intent was that they track a corresponding MachineOSConfig generation to do rebuilds, but in techpreview the implementation hasn't leveraged either field (hard set to 1). Let me check that and get back to you.

JoelSpeed · 2024-11-09T13:50:57Z

machineconfiguration/v1/types_machineosbuild.go

+	// host[:port][/namespace]/name:<tag> or svc_name.namespace.svc[:port]/repository/name:<tag>
+	// +kubebuilder:validation:MinLength=1
+	// +kubebuilder:validation:MaxLength=447
+	// +kubebuilder:validation:XValidation:rule=`((self.split(':').size() == 2 && self.split(':')[1].matches('^([a-zA-Z0-9-./:])+$')) || self.matches('^[^.]+\\.[^.]+\\.svc:\\d+\\/[^\\/]+\\/[^\\/]+:[^\\/]+$'))`,message="the OCI Image reference must end with a valid :<tag>, where '<digest>' is 64 characters long and '<tag>' is any valid string  Or it must be a valid .svc followed by a port, repository, image name, and tag."


The message here references digest, but it's not in the example?

JoelSpeed · 2024-11-09T14:03:42Z

machineconfiguration/v1/types_machineosbuild.go

+	// +listMapKey=type
+	// +optional
+	Conditions []metav1.Condition `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"`
+	// ImageBuilderType describes the image builder set in the MachineOSConfig


Godoc for this field is wrong, it's talking about a different field name?

machineconfiguration/v1/types_machineosconfig.go

JoelSpeed · 2024-11-09T16:05:56Z

machineconfiguration/v1/types_machineosconfig.go

+	// +kubebuilder:default:=noarch
+	// +optional
+	ContainerfileArch ContainerfileArch `json:"containerfileArch"`
+	// content is the custom content to be built


What is this? Can we expand this documentation?

JoelSpeed · 2024-11-09T16:05:59Z

machineconfiguration/v1/types_machineosconfig.go

+
+type MachineOSImageBuilder struct {
+	// imageBuilderType specifies the backend to be used to build the image.
+	// +kubebuilder:default:=PodImageBuilder


Are we sure we want this defaulted? What if we need to change this in the future as we decide there's a better, default image build method that doesn't rely on today's pod based image builder?

Is it difficult to change the default here in the API if we wanted to change it in the future?

When you have a default inside the API, you have to consider that this value will be written out to disk, and so, any existing instance of this API, will get this value and be stuck with it. If you wanted to, say, change blanketly even those instances that are already existing, then this makes it very difficult to change in the future.

We typically have a patten of "when omitted, this means no opinion, and the platform is left to choose a reasonable default, which is subject to change over time", which may be a better fit if you want a default here.

That said, I think the latest version of the API requires the user to specify this explicitly, which I think makes this a moot point

machineconfiguration/v1/types_machineosconfig.go

JoelSpeed · 2024-11-09T16:06:05Z

machineconfiguration/v1/types_machineosconfig.go

+	// +kubebuilder:validation:XValidation:rule=`((self.split(':').size() == 2 && self.split(':')[0].matches('^([a-zA-Z0-9-]+\\.)+[a-zA-Z0-9-]+(:[0-9]{2,5})?/([a-zA-Z0-9-_]{0,61}/)?[a-zA-Z0-9-_.]*?$')) || self.matches('^[^.]+\\.[^.]+\\.svc:\\d+\\/[^\\/]+\\/[^\\/]+:[^\\/]+$'))`,message="the OCI Image name should follow the host[:port][/namespace]/name format, resembling a valid URL without the scheme. Or it must be a valid .svc followed by a port, repository, image name, and tag."
+	// +kubebuilder:validation:Required
+	RenderedImagePushspec string `json:"renderedImagePushspec"`
+	// releaseVersion is associated with the base OS Image. This is the version of Openshift that the Base Image is associated with.


This line almost says the same thing twice, perhaps this should consolidate into one?

yuqi-zhang · 2024-11-15T02:17:03Z

Updated based on comments:
- Removed Version and ConfigGeneration from MOSB as they were unused
- Updated relatedobjects list
- Changed all optional,omitempty structs to pointers
- Removed default for ImageBuilderType, but keeping default build arch
to noarch as we don’t foresee changing that.
- Fixed RenderedImagePushspec validators to match description

Also temporarily reverted using format.dns1123subdomain() library while figuring out how it works

Mostly fixups, with some minor changes to the v1alpha1 API: - Removed Version and ConfigGeneration from MOSB as they were unused - Updated relatedobjects list - Changed all optional,omitempty structs to pointers - Removed default for ImageBuilderType, but keeping default build arch to noarch as we don’t foresee changing that. - Fixed RenderedImagePushspec validators to match description

yuqi-zhang · 2024-11-19T15:05:00Z

/test e2e-aws-serial-techpreview

umohnani8 · 2024-11-19T16:53:08Z

machineconfiguration/v1/types_machineosconfig.go

-	// describes that the machine-os-builder will use a custom pod builder that uses buildah
-	PodBuilder MachineOSImageBuilderType = "PodImageBuilder"
+	// describes that the machine-os-builder will use a Job to spin up a custom pod builder that uses buildah
+	PodBuilder MachineOSImageBuilderType = "JobImageBuilder"


Should this be renamed to JobBuilder as well?

cheesesashimi · 2024-11-19T17:06:24Z

machineconfiguration/v1/types_machineosbuild.go

 	// +unionMember
 	// +optional
-	PodImageBuilder *ObjectReference `json:"buildPod,omitempty"`
+	JobImageBuilderStatus *ObjectReference `json:"jobImageBuilderStatus,omitempty"`


I'm not sure that BuilderStatus makes sense here because this is mostly just a reference to the build executor which doesn't include any kind of status message (to my knowledge). Maybe something like JobImageBuilderRef or something like that would be more appropriate? Better yet, this could just be ImageBuilderRef. That, coupled with the value in ImageBuilderType, should be enough.

I think the comment above this field might need an update to reflect that it is a reference as well.

Stepping back a bit, I'm guessing the reason we are using a union here is we could have different builders, and they could need different types(other than ObjectReference) to represent their reference? If we are always going to use ObjectReference for multiple kind of builders, then maybe we don't even need to have to a union discriminator? It could be just two fields within this struct as Zack suggested: type and ref.

Those values are arguably common to all image builders. There could be some additional information that may be desired specific to each type of image builder, but we can add that onto this later as a specific type.

And taking a step back from this, if the ObjectReference includes GVK (Group Version Kind) information, we could potentially eliminate the ImageBuilderType field here since I see that as being primarily user-facing.

Ok, so instead of having individual ImageBuilderRef's, I'll just make it one optional field here to encompass all potential object references.

machineconfiguration/v1/types_machineosbuild.go

machineconfiguration/v1/types_machineosconfig.go

hack/update-payload-crds.sh

JoelSpeed · 2024-11-25T14:38:13Z

machineconfiguration/v1alpha1/types_machineosconfig.go

-	// +kubebuilder:validation:Required
-	BaseImagePullSecret ImageSecretObjectReference `json:"baseImagePullSecret"`
+	// must live in the openshift-machine-config-operator namespace if provided.
+	// defaults to using the cluster-wide pull secret if not specified.


Where is the default cluster wide pull-secret specified? Is this something users need to be aware of or is this something that is always set up and available?

Are there any security implications of relying on the default pull secret that we need to be aware of?

The cluster pull secret is the one in openshift-config namespace (just a secret called pull-secret). There shouldn't be any security implications - this is widely used, and is on-disk for every node as well as referenced in various MCO objects, and doesn't give any push access in most cases.

So maybe this should read something along the lines of, though, I'm not sure what registries it actually has read access to, does it have access to the in-cluster registry?

Suggested change

// defaults to using the cluster-wide pull secret if not specified.

// Defaults to using the cluster-wide pull secret, that was provided at install time.

// The default secret will provide read only access to registries <such as in cluster? RH owned? I don't know what this actually gives>.

I'll update the description in the v1 API. It does not, but we expect users to use the base shipped payload RHCOS image as the base image most of the time, so it should not be necessary.

JoelSpeed · 2024-11-25T14:38:50Z

machineconfiguration/v1alpha1/types_machineosconfig.go

+	// must live in the openshift-machine-config-operator namespace if provided.
+	// defaults to using the cluster-wide pull secret if not specified.
+	// +optional
+	BaseImagePullSecret ImageSecretObjectReference `json:"baseImagePullSecret,omitempty"`


ImageSecretObjectReference is a struct right? To actually omit this, it needs to be a pointer

Ah, will update that as well. I originally updated the v1alpha1 API first via the first commit before updated it all to the correct version in v1. I don't think this is technically needed anymore?

Basically the v1 API has all the updates from comments, and we will remove the v1alpha1 API after we switch all references, hence why I haven't updated the v1alpha1 API. Is that generally the expected pattern?

Yeah generally you can leave the v1alpha1 API alone, I just checked it as you had made changes in it. You shouldn't need to add this here if it's being added strictly to the new v1 API

machineconfiguration/v1/types_machineosbuild.go

JoelSpeed · 2024-11-25T14:47:52Z

machineconfiguration/v1/types_machineosbuild.go

+type MachineOSBuildStatus struct {
+	// conditions are state related conditions for the build. Valid types are:
+	// Prepared, Building, Failed, Interrupted, and Succeeded
+	// once a Build is marked as Failed, no future conditions can be set. This is enforced by the MCO.


You could enforce that using CEL, IIUC, a condition marking this as failed, makes the list immutable?

How is it enforced by MCO today?

// +kubebuilder:validation:XValidation:rule="self.exists(x, x.type == 'Failed') ? self == oldSelf : true",message="once a Failed condition is set, conditions are immutable"

The expectation is that only the MCO will be creating MachineOSBuild objects (so the user cannot directly create a build like that, they must create a config from which build objects are created by the MCO as it does the builds). In that sense, this status is monitored and updated by the MCO.

Do you think it's strictly necessary given the context?

Yeah I would still add the validation. Users have access to APIs, and may do unexpected things. Controllers also have bugs, that make them do weird things. The more we can put into the API validation to make sure it meets our expectations, the better, even in status

I agree. I'd also like to point out that Interrupted should also be considered an immutable state.

machineconfiguration/v1/types_machineosconfig.go

JoelSpeed · 2024-11-25T16:58:34Z

machineconfiguration/v1/types_machineosconfig.go

+	// +kubebuilder:validation:MaxLength=447
+	// +kubebuilder:validation:XValidation:rule=`self.matches('^([a-zA-Z0-9-]+\\.)+[a-zA-Z0-9-]+(:[0-9]{2,5})?(/[a-zA-Z0-9-_]{1,61})*/[a-zA-Z0-9-_.]+:[a-zA-Z0-9._-]+$') || self.matches('^[^.]+\\.[^.]+\\.svc:\\d+\\/[^\\/]+\\/[^\\/]+:[^\\/]+$')`,message="the OCI Image name should follow the host[:port][/namespace]/name format, resembling a valid URL without the scheme. Or it must be a valid .svc followed by a port, repository, image name, and tag."
+	// +kubebuilder:validation:Required
+	RenderedImagePushspec string `json:"renderedImagePushspec"`


Is a Pushspec a thing or should this be PushSpec?

yuqi-zhang · 2024-11-26T02:57:12Z

Thanks for the thorough review. Addressed most of the comments, left a few questions, and will follow up on the 3 points above.

I see the o/k PR for adding the format library has merged. Will try to incorporate that into the next set of changes as well.

- Update from PodImageBuilder to JobImageBuilder, and add a MachineOSBuild reference to MachineOSConfig - Failed and Interrupted will now cause MOSBuild conditions to be immutable - Updated Arch enum to be PascalCase - Updated relatedObject go doc based on suggestion - Add validation for buildEnd > buildStart - Removed conditions field from MOSConfig. The build object is supposed to reflect conditions instead, so this is not needed at this time - Use dns1123 format check for all strings that match, and otherwise switch pattern checks to validation rules where appropriate - Updated godocs a bit more for formatting

yuqi-zhang · 2024-11-29T01:07:30Z

Pushed another set of updates:

Failed and Interrupted will now cause MOSBuild conditions to be immutable
Updated Arch enum to be PascalCase (kept x86_64 though)
Updated relatedObject go doc based on suggestion
Add validation for buildEnd > buildStart (did not add ordering requirement, as buildStart is a required field, and will be applied before or at the same time of buildEnd)
Removed conditions field from MOSConfig -> the build object is supposed to reflect conditions instead, so this is not needed at this time
Use dns1123 format check for all strings that match, and otherwise switch pattern checks to validation rules where appropriate
Updated godocs a bit more for formatting

Tested on the latest 4.18 nightly and can confirm both CRDs are valid with the new format library

JoelSpeed · 2024-11-29T13:10:37Z

...configuration/v1/tests/machineosbuilds.machineconfiguration.openshift.io/OnClusterBuild.yaml

+        machineOSConfig:
+          name: worker
+        renderedImagePushspec: quay.io/mco/renderedImage:latest
+  onCreate:


You don't need the second onCreate here

JoelSpeed · 2024-11-29T13:11:05Z

...onfiguration/v1/tests/machineosconfigs.machineconfiguration.openshift.io/OnClusterBuild.yaml

+        buildOutputs:
+          currentImagePullSecret:
+            name: foo
+    onCreate:


Remove additional onCreates, only expecting one in the file

JoelSpeed · 2024-11-29T13:12:05Z

...onfiguration/v1/tests/machineosconfigs.machineconfiguration.openshift.io/OnClusterBuild.yaml

+          name: worker
+        buildInputs:
+          imageBuilder: 
+            imageBuilderType: JobImageBuilder


Do we really want the repetition of imageBuilder and imageBuilderType? And in the enum value as well?

imageBuilder: type: Job

JoelSpeed · 2024-11-29T13:12:48Z

...onfiguration/v1/tests/machineosconfigs.machineconfiguration.openshift.io/OnClusterBuild.yaml

+          renderedImagePushSecret:
+            name: foo
+          renderedImagePushspec: quay.io/mco/renderedImg:latest


Push stuff feels more like an output to me?

The user should be specifying where to push to here, so it is user input

JoelSpeed · 2024-11-29T13:14:06Z

...onfiguration/v1/tests/machineosconfigs.machineconfiguration.openshift.io/OnClusterBuild.yaml

+        buildOutputs:
+          currentImagePullSecret:
+            name: foo
+    expectedError: "Invalid value: \"string\": the OCI Image name should follow the host[:port][/namespace]/name format, resembling a valid URL without the scheme"


Could you include the earlier part of the error that shows which field this pertains to, that way it's easier to find the broken field when reviewing this later

JoelSpeed · 2024-11-29T15:11:29Z

machineconfiguration/v1/types_machineosconfig.go

+}
+
+// BuildInputs holds all of the information needed to trigger a build
+type BuildInputs struct {


As a user of this API, how would I know what a BaseOSExtensions vs BaseOS vs Base image means?

I'm wondering if we can clean this API up a bit, there's a lot of, what appears to a naive eye at least, redundancy?

images: base: <> baseOS: <> baseOSExtensions: <> pullSecret: name: <> pushSecret: name: <> builder: type: Job job: name: <> pushSpec: <> releaseVersion: <> containerFiles: []

Or if we moved up to spec, some of this might look like

sourceImages: pullSecret: <> # For pulling these images base: <> baseOS: <> baseOSExtensions: <> buildOutputs: pullSecret: name: <> # For pulling the pushed image pushSecret: name: <> # For pushing the built image imagePushSpec: <> builder: type: Job job: name: <> releaseVersion: <> containerFiles: []

JoelSpeed · 2024-11-29T15:19:21Z

machineconfiguration/v1/types_machineosconfig.go

+	// containerfileArch describes the architecture this containerfile is to be built for.
+	// This arch is optional. If the user does not specify an architecture, it is assumed
+	// that the content can be applied to all architectures, or in a single arch cluster: the only architecture.
+	// +kubebuilder:validation:Enum:=ARM64;AMD64;PPC64LE;S390X;AArch64;x86_64;NoArch


Why do we have these duplicates? That means an end user can configure the same meaning, in multiple ways, that's confusing, we should avoid that

Suggested change

// +kubebuilder:validation:Enum:=ARM64;AMD64;PPC64LE;S390X;AArch64;x86_64;NoArch

// +kubebuilder:validation:Enum:=ARM64;AMD64;PPC64LE;S390X;NoArch

JoelSpeed · 2024-11-29T15:20:10Z

machineconfiguration/v1/types_machineosconfig.go

+	// containerFile describes the custom data the user has specified to build into the image.
+	// This is also commonly called a Dockerfile and you can treat it as such. The content is the content of your Dockerfile.
+	// See https://github.com/containers/common/blob/main/docs/Containerfile.5.md for the spec reference.
+	// you can specify up to 7 containerFiles


What does it mean to specify multiple images? Why would an end user want to do that?

JoelSpeed · 2024-11-29T15:21:31Z

machineconfiguration/v1/types_machineosconfig.go

+	CurrentImagePullSecret *ImageSecretObjectReference `json:"currentImagePullSecret,omitempty"`
+}
+
+type MachineOSImageBuilder struct {


When this struct is used, it's called something like imageBuilder, maybe we avoid the repetition here and go for just type for the field within here?

JoelSpeed · 2024-11-29T15:22:08Z

machineconfiguration/v1/types_machineosconfig.go

+// the MachineOSBuilder pod validates that the user has provided a valid pool
+type MachineConfigPoolReference struct {
+	// name of the MachineConfigPool object.
+	// Must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character.


Should update this to match the others I suggested, including the at most 253 characters part

Mostly fixes around validation and godocs. Added some additional test cases.

openshift-ci · 2024-12-03T02:58:39Z

@yuqi-zhang: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-serial	`0741c21`	link	true	`/test e2e-aws-serial`
ci/prow/e2e-aws-ovn-hypershift	`0741c21`	link	true	`/test e2e-aws-ovn-hypershift`
ci/prow/e2e-gcp	`0741c21`	link	false	`/test e2e-gcp`
ci/prow/e2e-aws-serial-techpreview	`0741c21`	link	true	`/test e2e-aws-serial-techpreview`
ci/prow/integration	`8f073d7`	link	true	`/test integration`

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.

openshift-ci bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Nov 7, 2024

MachineOSConfig: set ImageSecretObjectReference to optional

25814d6

yuqi-zhang force-pushed the promote-onclusterbuild branch from 8465feb to 2ca4842 Compare November 8, 2024 18:01

Add v1 versions of OnClusterBuild APIs

4c9f154

First step to GA'ing the currently v1alpha1 APIs. Don't add to payload manifests yet, and the featuregate is retained.

yuqi-zhang force-pushed the promote-onclusterbuild branch from 2ca4842 to 4c9f154 Compare November 8, 2024 22:22

yuqi-zhang marked this pull request as ready for review November 8, 2024 22:26

openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 8, 2024

yuqi-zhang changed the title ~~Promote onclusterbuild to GA~~ MCO-1443: Promote onclusterbuild to GA Nov 8, 2024

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Nov 8, 2024

openshift-ci bot requested review from jkyros and JoelSpeed November 8, 2024 22:26

JoelSpeed reviewed Nov 9, 2024

View reviewed changes

yuqi-zhang force-pushed the promote-onclusterbuild branch 3 times, most recently from 60085e1 to 416f317 Compare November 15, 2024 02:16

Temporarily exclude v1 MOSC/MOSB from payload

8b77960

yuqi-zhang force-pushed the promote-onclusterbuild branch 2 times, most recently from a663367 to 8f72efb Compare November 15, 2024 06:31

yuqi-zhang force-pushed the promote-onclusterbuild branch from 8f72efb to c6619bf Compare November 15, 2024 16:05

yuqi-zhang mentioned this pull request Nov 15, 2024

MCO-1443: Promote onclusterbuild to GA - option 2 #2100

Open

umohnani8 reviewed Nov 19, 2024

View reviewed changes

cheesesashimi reviewed Nov 19, 2024

View reviewed changes

yuqi-zhang force-pushed the promote-onclusterbuild branch 3 times, most recently from 7597202 to ddb8b4e Compare November 19, 2024 17:50

cheesesashimi reviewed Nov 19, 2024

View reviewed changes

machineconfiguration/v1/types_machineosbuild.go Show resolved Hide resolved

yuqi-zhang force-pushed the promote-onclusterbuild branch from ddb8b4e to dd3b585 Compare November 19, 2024 19:28

cheesesashimi reviewed Nov 20, 2024

View reviewed changes

machineconfiguration/v1/types_machineosconfig.go Outdated Show resolved Hide resolved

yuqi-zhang force-pushed the promote-onclusterbuild branch from dd3b585 to 44656cf Compare November 20, 2024 22:25

JoelSpeed reviewed Nov 25, 2024

View reviewed changes

yuqi-zhang force-pushed the promote-onclusterbuild branch from 0741c21 to 7ff1e4d Compare November 29, 2024 01:06

JoelSpeed reviewed Nov 29, 2024

View reviewed changes

yuqi-zhang mentioned this pull request Dec 3, 2024

MCO-1284: MachineOSConfig: set ImageSecretObjectReference to optional #2089

Closed

Additional MOSC/MOSB updates

8f073d7

Mostly fixes around validation and godocs. Added some additional test cases.

		@@ -0,0 +1,64 @@
		apiVersion: apiextensions.k8s.io/v1 # Hack because controller-gen complains if we don't have this
		name: "[TechPreview] MachineOSBuild"

		@@ -0,0 +1,134 @@
		apiVersion: apiextensions.k8s.io/v1 # Hack because controller-gen complains if we don't have this
		name: "[TechPreview] MachineOSConfig"

	// defaults to using the cluster-wide pull secret if not specified.
	// Defaults to using the cluster-wide pull secret, that was provided at install time.
	// The default secret will provide read only access to registries <such as in cluster? RH owned? I don't know what this actually gives>.

	// +kubebuilder:validation:Enum:=ARM64;AMD64;PPC64LE;S390X;AArch64;x86_64;NoArch
	// +kubebuilder:validation:Enum:=ARM64;AMD64;PPC64LE;S390X;NoArch

MCO-1443: Promote onclusterbuild to GA #2090

Are you sure you want to change the base?

MCO-1443: Promote onclusterbuild to GA #2090

Conversation

yuqi-zhang commented Nov 7, 2024 • edited Loading

openshift-ci bot commented Nov 7, 2024

openshift-ci bot commented Nov 7, 2024

openshift-ci bot commented Nov 7, 2024

yuqi-zhang commented Nov 8, 2024

yuqi-zhang commented Nov 8, 2024

openshift-ci-robot commented Nov 8, 2024 • edited by openshift-ci bot Loading

JoelSpeed left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yuqi-zhang commented Nov 15, 2024

yuqi-zhang commented Nov 19, 2024

Choose a reason for hiding this comment

cheesesashimi Nov 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yuqi-zhang Nov 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yuqi-zhang commented Nov 26, 2024

yuqi-zhang commented Nov 29, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openshift-ci bot commented Dec 3, 2024

yuqi-zhang commented Nov 7, 2024 •

edited

Loading

openshift-ci-robot commented Nov 8, 2024 •

edited by openshift-ci bot

Loading

cheesesashimi Nov 19, 2024 •

edited

Loading

yuqi-zhang Nov 25, 2024 •

edited

Loading