AGENT-1330: machineconfiguration/v1alpha1: add InternalReleaseImage

[andfasano]

This patch adds the new InternalReleaseImage CRD. See openshift/enhancements#1821 for additional details

[openshift-ci-robot]

@andfasano: This pull request references AGENT-1330 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.21.0" version, but no target version was set.

In response to this:

This patch adds the new InternalReleaseImage CRD. See openshift/enhancements#1821 for additional details

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]

Hello @andfasano! 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.

[andfasano]

/retest-required

[JoelSpeed]

I'm currently experimenting with AI for API review, hopefully some of the content it is generating is helpful for you to improve your API

The following code blocks were generated by Claude

⏺ I'll run a comprehensive API review for PR #2510. Let me start by setting up the environment and checking out the PR.

⏺ Bash(CURRENT_BRANCH=$(git branch --show-current); echo "📍 Current branch: $CURRENT_BRANCH"; if ! git diff --quiet || ! git diff --cached --quiet; then echo "❌ ERROR…)
  ⎿  📍 Current branch: agents                           
     ✅ No uncommitted changes detected. Safe to proceed.

⏺ Bash(echo "🔍 Reviewing PR #2510"; echo "🔄 Checking out PR #2510..."; gh pr checkout "2510")
  ⎿  🔍 Reviewing PR #2510                
     🔄 Checking out PR #2510...
     From https://github.com/openshift/api
     … +2 lines (ctrl+o to expand)

⏺ Bash(echo "📁 Analyzing changed files..."; gh pr view "2510" --json files --jq '.files[].path' | grep '\.go$' | grep -E '/(v1|v1alpha1|v1beta1)/')
  ⎿  📁 Analyzing changed files...                              
     machineconfiguration/v1alpha1/register.go
     machineconfiguration/v1alpha1/types_internalreleaseimage.go
     … +2 lines (ctrl+o to expand)

⏺ Bash(echo "⏳ Running linting checks on PR changes..."; make lint)
  ⎿  Error: make: *** [lint] Error 1

     ⏳ Running linting checks on PR changes...
     hack/golangci-lint.sh run --new-from-rev=master 
     Tools vendor version mismatch, removing old utils
     Writing tools vendor version 206d340a14a3ede2d30e25b37757397aacac6799
     go build -mod=vendor -o /Users/jspeed/go/src/github.com/openshift/api/tools/_output/bin/darwin/arm64/golangci-lint ./vendor/github.com/golangci/golangci-lint/v2/cmd/golangci-lint
     go build -mod=vendor -buildmode=plugin -o /Users/jspeed/go/src/github.com/openshift/api/tools/_output/bin/darwin/arm64/kube-api-linter.so ./vendor/sigs.k8s.io/kube-api-linter/pkg/plugin
     ln -fs /Users/jspeed/go/src/github.com/openshift/api/tools/_output/bin/darwin/arm64/kube-api-linter.so /Users/jspeed/go/src/github.com/openshift/api/tools/_output/bin/kube-api-linter.so
     machineconfiguration/v1alpha1/types_internalreleaseimage.go:35:2: requiredfields: field Spec has a valid zero value ({}), but the validation is not complete (e.g. min properties/adding required fields). The field should be a pointer to allow the zero value to be set. If the zero value is not a valid use case, complete the validation and remove the 
     pointer. (kubeapilinter)
     … +7 lines (ctrl+o to see all)

⏺ Now let me analyze the main API file for documentation requirements:

⏺ Read(machineconfiguration/v1alpha1/types_internalreleaseimage.go)
  ⎿  Read 111 lines (ctrl+o to expand)

⏺ Let me also check the PR diff to understand exactly what changed:

⏺ Bash(gh pr diff "2510")
  ⎿  diff --git a/machineconfiguration/v1alpha1/register.go b/machineconfiguration/v1alpha1/register.go
     index c60f521f940..451be959977 100644
     --- a/machineconfiguration/v1alpha1/register.go
     … +601 lines (ctrl+o to expand)

⏺ API Review Report for PR #2510

  ❌ REVIEW FAILED - Issues Found

  The API review has identified several critical issues that must be addressed before this PR can be approved.

  🚨 Linting Errors (CRITICAL)

  The make lint command failed with kubeapilinter errors:

  +35: Spec field validation issue
  Current (problematic) code:
  Spec InternalReleaseImageSpec `json:"spec,omitzero"`

  Suggested change:
  - Spec InternalReleaseImageSpec `json:"spec,omitzero"`
  + Spec *InternalReleaseImageSpec `json:"spec,omitzero"`

  Explanation: The field has a valid zero value ({}) but incomplete validation. Since it's marked as +required, it should be a pointer to allow the zero value to be set, or the validation should be completed to make the zero value invalid.

  +39: Status field validation issue
  Current (problematic) code:
  Status InternalReleaseImageStatus `json:"status"`

  Suggested change:
  - Status InternalReleaseImageStatus `json:"status"`
  + Status *InternalReleaseImageStatus `json:"status"`

  Explanation: The field has a valid zero value ({}) but incomplete validation. Since status subresources typically allow empty initial states, this should be a pointer to allow the zero value to be set.

  📚 Documentation Issues (MODERATE)

  +48: Missing optional field behavior documentation
  Current (problematic) code:
  // conditions represent the observations of an internal release image current state.
  // +listType=map
  // +listMapKey=type
  // +kubebuilder:validation:MaxItems=20
  // +optional
  Conditions []metav1.Condition `json:"conditions,omitempty"`

  Suggested change:
  - // conditions represent the observations of an internal release image current state.
  + // conditions represent the observations of an internal release image current state.
  + // When omitted, the resource has no status conditions to report.

  Explanation: Optional fields must explain what happens when they are omitted. The field comment should state the behavior when the field is not present.

  +57: Missing optional field behavior documentation
  Current (problematic) code:
  // availableReleases is a list of release bundle identifiers currently detected
  // from the attached ISO.
  // +listType=map
  // +listMapKey=name
  // +kubebuilder:validation:MinItems=1
  // +kubebuilder:validation:MaxItems=64
  // +optional
  AvailableReleases []InternalReleaseImageRef `json:"availableReleases,omitempty"`

  Suggested change:
  - // availableReleases is a list of release bundle identifiers currently detected
  - // from the attached ISO.
  + // availableReleases is a list of release bundle identifiers currently detected
  + // from the attached ISO.
  + // When omitted or empty, no release bundles have been detected from the attached ISO.

  Explanation: Optional fields must explain what happens when they are omitted. Also, the validation constraints (MinItems=1, MaxItems=64) should be documented.

  +66: Missing optional field behavior documentation
  Current (problematic) code:
  // releases is a list of the currently managed release bundles.
  // +listType=map
  // +listMapKey=name
  // +kubebuilder:validation:MinItems=1
  // +kubebuilder:validation:MaxItems=64
  // +optional
  Releases []InternalReleaseImageRef `json:"releases,omitempty"`

  Suggested change:
  - // releases is a list of the currently managed release bundles.
  + // releases is a list of the currently managed release bundles.
  + // When omitted or empty, no release bundles are currently being managed.

  Explanation: Optional fields must explain what happens when they are omitted. Also, the validation constraints (MinItems=1, MaxItems=64) should be documented.

  +78: Missing optional field behavior documentation
  Current (problematic) code:
  // releases is a list of release bundle identifiers that the user wants to
  // add/remove to/from the control plane nodes.
  // +optional
  // +kubebuilder:validation:MinItems=1
  // +kubebuilder:validation:MaxItems=20
  // +listType=map
  // +listMapKey=name
  Releases []InternalReleaseImageRef `json:"releases,omitempty"`

  Suggested change:
  - // releases is a list of release bundle identifiers that the user wants to
  - // add/remove to/from the control plane nodes.
  + // releases is a list of release bundle identifiers that the user wants to
  + // add/remove to/from the control plane nodes.
  + // When omitted or empty, no release bundle operations are requested.
  + // Must contain between 1 and 20 items when specified.

  Explanation: Optional fields must explain what happens when they are omitted. The validation constraints (MinItems=1, MaxItems=20) must also be documented in the field comment.

  +93: Missing optional field behavior documentation
  Current (problematic) code:
  // image is an OCP release imaged referenced by digest.
  // The format of the image pull spec is: host[:port][/namespace]/name@sha256:<digest>,
  // where the digest must be 64 characters long, and consist only of lowercase hexadecimal characters, a-f and 0-9.
  // The length of the whole spec must be between 1 to 447 characters.
  // +optional
  Image machineosconfig.ImageDigestFormat `json:"image,omitempty"`

  Suggested change:
  - // image is an OCP release imaged referenced by digest.
  - // The format of the image pull spec is: host[:port][/namespace]/name@sha256:<digest>,
  - // where the digest must be 64 characters long, and consist only of lowercase hexadecimal characters, a-f and 0-9.
  - // The length of the whole spec must be between 1 to 447 characters.
  + // image is an OCP release imaged referenced by digest.
  + // The format of the image pull spec is: host[:port][/namespace]/name@sha256:<digest>,
  + // where the digest must be 64 characters long, and consist only of lowercase hexadecimal characters, a-f and 0-9.
  + // The length of the whole spec must be between 1 to 447 characters.
  + // When omitted, the release bundle identifier refers to the name only without an associated image.

  Explanation: Optional fields must explain what happens when they are omitted. This field needs to clarify what happens when no image is specified for a release bundle.

  ✅ Positive Findings

  - API Structure: Well-organized with appropriate separation between spec and status
  - Feature Gate: Properly gated behind NoRegistryClusterOperations feature gate
  - Validation Rules: Comprehensive validation using kubebuilder markers and CEL expressions
  - Generated Files: All required generated files (deepcopy, CRDs, swagger docs) are present and properly updated
  - List Support: Proper list type and map key annotations for array fields
  - Compatibility: Correctly marked as compatibility level 4 for alpha API

  📋 Action Required

  1. CRITICAL: Fix the linting errors by addressing the pointer vs value type issues for Spec and Status fields
  2. REQUIRED: Add proper documentation for all optional fields explaining behavior when omitted
  3. RECOMMENDED: Document validation constraints in field comments for better developer experience

  The PR cannot be approved until the critical linting errors are resolved and all optional fields have proper behavior documentation.

I think the linting issues are actually not the response I'd like. Instead lets try and make the zero values not valid (required fields or MinProperties markers. The linter should be prompting you on these already

For the comments, it has highlighted that you haven't explained what happens when the optional fields are omitted, though I'm not sure its suggestions are super helpful, please review and think about what you'd actually like to put in. If it has identified something where you can't think of a reason why it wouldn't be present, then maybe the field should actually be required

---

Quizzing specifically about whether all validations were documented, some further output

⏺ You're absolutely right. Looking more carefully at the validation markers, I missed several undocumented validation markers:

  Additional Undocumented Validation Markers I Missed:

  +47: MaxItems validation not documented
  // +kubebuilder:validation:MaxItems=20
  The comment doesn't mention the maximum of 20 items for conditions.

  +55-56: MinItems and MaxItems validation not documented
  // +kubebuilder:validation:MinItems=1
  // +kubebuilder:validation:MaxItems=64
  The comment doesn't mention the 1-64 item range for availableReleases.

  +63-64: MinItems and MaxItems validation not documented
  // +kubebuilder:validation:MinItems=1  
  // +kubebuilder:validation:MaxItems=64
  The comment doesn't mention the 1-64 item range for releases in status.

  +84-85: MinLength and MaxLength validation not documented
  // +kubebuilder:validation:MinLength=1
  // +kubebuilder:validation:MaxLength=64
  The comment doesn't mention the 1-64 character length constraints for the name field.

  So no, my original review was incomplete. I identified the optional field behavior issues but missed documenting several validation constraints that should be included in the field comments according to OpenShift API documentation standards.

[andfasano]

/api-review

[andfasano]

/test verify

[andfasano]

/verified later @andfasano

[openshift-ci-robot]

@andfasano: This PR has been marked to be verified later by @andfasano.

In response to this:

/verified later @andfasano

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]

/retest-required

Remaining retests: 0 against base HEAD fc06468 and 2 for PR HEAD 463ca8c in total

[openshift-ci-robot]

/retest-required

Remaining retests: 0 against base HEAD 1ef028d and 1 for PR HEAD 463ca8c in total

[andfasano]

/retest-required

[openshift-ci]

@andfasano: The following test 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/okd-scos-e2e-aws-ovn	38f68b3	link	false	/test okd-scos-e2e-aws-ovn

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-robot]

/retest-required

Remaining retests: 0 against base HEAD 88cca31 and 0 for PR HEAD 463ca8c in total

[coderabbitai]

Actionable comments posted: 2

♻️ Duplicate comments (3)

machineconfiguration/v1/types_machineconfignode.go (1)

161-184: Verify zero‑value handling and invariants for InternalReleaseImage status

MachineConfigNodeStatus.InternalReleaseImage is a value field with json:"internalReleaseImage,omitzero,omitempty" and the nested type requires a non‑empty releases slice (+required, MinItems=1, MaxItems=32).

This implies two important invariants:

1. The codecs you use for status updates must treat ,omitzero the same way as for ConfigImage, i.e. omit internalReleaseImage entirely when the struct is at its zero value, so we never persist internalReleaseImage: {} without releases.
2. All writers of MachineConfigNodeStatus.InternalReleaseImage must only populate this field when they also set Releases to a non‑empty slice that satisfies the CRD constraints; an update with an empty/nil Releases would be rejected by the API server.

Please double‑check both the serialization behavior and controller logic to ensure these invariants hold in practice.

openapi/generated_openapi/zz_generated.openapi.go (1)

43450-43612: Documented constraints for name, image, and releases are not enforced in the schema

The descriptions declare strict constraints, but the generated OpenAPI does not enforce them:

• Line 43450 (InternalReleaseImageBundleStatus.name) and line 43530 (InternalReleaseImageRef.name) say the name “must be between 1 and 64 characters long”, but there is no minLength/maxLength on these string schemas.
• Line 43457 (InternalReleaseImageBundleStatus.image) documents a digest-based pull spec with a 64‑char hex digest and total length 1–447, but the schema is just a plain string with no minLength/maxLength or pattern.
• Line 43551 (InternalReleaseImageSpec.releases) says the list “must contain at least one entry and must not exceed 16 entries,” but there is no minItems/maxItems.
• Line 43589 (InternalReleaseImageStatus.releases) similarly says the list must have at least 1 and at most 32 entries, but again there is no minItems/maxItems.

This mismatch means invalid objects that violate the documented “must” constraints remain schema‑valid, which weakens API guarantees and tooling (validation, CRD UX, etc.).

Because this file is generated, the fix should be in the Go API types:

• Add kubebuilder validation markers for the name fields, e.g. +kubebuilder:validation:MinLength=1 and +kubebuilder:validation:MaxLength=64.
• Add MinLength, MaxLength, and a Pattern marker for image to enforce the digest pull‑spec shape (e.g. ^.+@sha256:[a-f0-9]{64}$ with appropriate length bounds).
• Add +kubebuilder:validation:MinItems=1 / MaxItems=16 for spec.releases and MinItems=1 / MaxItems=32 for status.releases.

Then regenerate the OpenAPI so this schema reflects the documented behavior.

openapi/openapi.json (1)

25041-25186: Add missing schema validation attributes to match documented constraints.

The OpenAPI schema includes validation constraints in field documentation (e.g., "between 1 and 64 characters", "must not exceed 16 entries") but these constraints are not reflected as schema validation attributes (minLength, maxLength, minItems, maxItems). This means API clients using this schema won't discover the enforced constraints.

Required additions:

• minLength: 1, maxLength: 64 for all name fields (lines 25097, 25140)
• minLength: 1, maxLength: 447 for image field (line 25093)
• minItems: 1, maxItems: 16 for spec.releases (line 25153)
• minItems: 1, maxItems: 32 for status.releases (line 25174)

Since this file is auto-generated from Go types, ensure that types_internalreleaseimage.go contains the corresponding +kubebuilder:validation markers (e.g., +kubebuilder:validation:MinLength=1, +kubebuilder:validation:MaxItems=16), then regenerate the OpenAPI schema.

🧹 Nitpick comments (3)

payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-TechPreviewNoUpgrade.crd.yaml (1)

355-486: Clarify optional vs. required behavior for internalReleaseImage.

The internalReleaseImage field is omittable from status (not in required fields), but its nested releases array mandates minItems: 1 (line 479). The description adequately explains "When specified, an internalReleaseImage custom resource exists on the cluster", but it's unclear whether this field should ever be empty. If internalReleaseImage is present, releases must have at least one entry; if truly optional, this is correct. However, consider adding a note to clarify that the field should only be included when release images are actually tracked on the node.

Enhance the description at line 356–359 to explicitly state: "When omitted, no internal release images are tracked on this node. When present, the releases array must contain at least one entry and will reflect the on-disk state."

machineconfiguration/v1alpha1/types_internalreleaseimage.go (2)

44-54: Document the add/remove workflow for releases.

The documentation should clarify:

• That releases added to this list must already be mounted on at least one control plane node
• That removing a release from this list triggers removal from the internal registry
• The lifecycle: mounted → added to spec → installed → available for use

Consider expanding the godoc similar to the suggestion in past review comments to make the user workflow clearer.

Based on past review comments requesting clearer workflow documentation.

---

70-82: Consider clarifying the status.releases lifecycle.

While the documentation is clear about when releases can be safely used, consider adding a sentence about when this field is populated. For example: "This field is populated by the controller after discovering mounted releases on control plane nodes."

This would help users understand the flow from spec to status.

Based on past review comments suggesting lifecycle documentation.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 463ca8c and 7a0d946.

📒 Files selected for processing (38)

• hack/update-payload-crds.sh (1 hunks)
• machineconfiguration/v1/tests/machineconfignodes.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml (1 hunks)
• machineconfiguration/v1/types_machineconfignode.go (1 hunks)
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-CustomNoUpgrade.crd.yaml (1 hunks)
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-Default.crd.yaml (1 hunks)
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-DevPreviewNoUpgrade.crd.yaml (0 hunks)
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-TechPreviewNoUpgrade.crd.yaml (0 hunks)
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-CustomNoUpgrade.crd.yaml (1 hunks)
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-Default.crd.yaml (0 hunks)
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-DevPreviewNoUpgrade.crd.yaml (1 hunks)
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-TechPreviewNoUpgrade.crd.yaml (1 hunks)
• machineconfiguration/v1/zz_generated.deepcopy.go (2 hunks)
• machineconfiguration/v1/zz_generated.featuregated-crd-manifests.yaml (1 hunks)
• machineconfiguration/v1/zz_generated.featuregated-crd-manifests/machineconfignodes.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml (1 hunks)
• machineconfiguration/v1/zz_generated.swagger_doc_generated.go (2 hunks)
• machineconfiguration/v1alpha1/register.go (1 hunks)
• machineconfiguration/v1alpha1/tests/internalreleaseimages.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml (1 hunks)
• machineconfiguration/v1alpha1/types_internalreleaseimage.go (1 hunks)
• machineconfiguration/v1alpha1/zz_generated.crd-manifests/0000_80_machine-config_01_internalreleaseimages-CustomNoUpgrade.crd.yaml (1 hunks)
• machineconfiguration/v1alpha1/zz_generated.crd-manifests/0000_80_machine-config_01_internalreleaseimages-DevPreviewNoUpgrade.crd.yaml (1 hunks)
• machineconfiguration/v1alpha1/zz_generated.crd-manifests/0000_80_machine-config_01_internalreleaseimages-TechPreviewNoUpgrade.crd.yaml (1 hunks)
• machineconfiguration/v1alpha1/zz_generated.deepcopy.go (1 hunks)
• machineconfiguration/v1alpha1/zz_generated.featuregated-crd-manifests.yaml (1 hunks)
• machineconfiguration/v1alpha1/zz_generated.featuregated-crd-manifests/internalreleaseimages.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml (1 hunks)
• machineconfiguration/v1alpha1/zz_generated.swagger_doc_generated.go (1 hunks)
• openapi/generated_openapi/zz_generated.openapi.go (2 hunks)
• openapi/openapi.json (2 hunks)
• payload-manifests/crds/0000_80_machine-config_01_internalreleaseimages-CustomNoUpgrade.crd.yaml (1 hunks)
• payload-manifests/crds/0000_80_machine-config_01_internalreleaseimages-DevPreviewNoUpgrade.crd.yaml (1 hunks)
• payload-manifests/crds/0000_80_machine-config_01_internalreleaseimages-TechPreviewNoUpgrade.crd.yaml (1 hunks)
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-Hypershift-CustomNoUpgrade.crd.yaml (1 hunks)
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-Hypershift-Default.crd.yaml (1 hunks)
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-Hypershift-DevPreviewNoUpgrade.crd.yaml (0 hunks)
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-Hypershift-TechPreviewNoUpgrade.crd.yaml (0 hunks)
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-CustomNoUpgrade.crd.yaml (1 hunks)
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-Default.crd.yaml (0 hunks)
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-DevPreviewNoUpgrade.crd.yaml (1 hunks)
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-TechPreviewNoUpgrade.crd.yaml (1 hunks)

💤 Files with no reviewable changes (6)

• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-Default.crd.yaml
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-TechPreviewNoUpgrade.crd.yaml
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-Hypershift-TechPreviewNoUpgrade.crd.yaml
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-Default.crd.yaml
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-Hypershift-DevPreviewNoUpgrade.crd.yaml
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-DevPreviewNoUpgrade.crd.yaml

🚧 Files skipped from review as they are similar to previous changes (5)

• machineconfiguration/v1alpha1/register.go
• hack/update-payload-crds.sh
• machineconfiguration/v1alpha1/zz_generated.crd-manifests/0000_80_machine-config_01_internalreleaseimages-TechPreviewNoUpgrade.crd.yaml
• machineconfiguration/v1alpha1/zz_generated.featuregated-crd-manifests.yaml
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-Hypershift-Default.crd.yaml

🧰 Additional context used

📓 Path-based instructions (1)

**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

• machineconfiguration/v1alpha1/tests/internalreleaseimages.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml
• machineconfiguration/v1alpha1/types_internalreleaseimage.go
• payload-manifests/crds/0000_80_machine-config_01_internalreleaseimages-CustomNoUpgrade.crd.yaml
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-CustomNoUpgrade.crd.yaml
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-DevPreviewNoUpgrade.crd.yaml
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-TechPreviewNoUpgrade.crd.yaml
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-DevPreviewNoUpgrade.crd.yaml
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-Default.crd.yaml
• machineconfiguration/v1/types_machineconfignode.go
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-Hypershift-CustomNoUpgrade.crd.yaml
• machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-CustomNoUpgrade.crd.yaml
• openapi/generated_openapi/zz_generated.openapi.go
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-TechPreviewNoUpgrade.crd.yaml
• machineconfiguration/v1/zz_generated.featuregated-crd-manifests/machineconfignodes.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml
• machineconfiguration/v1alpha1/zz_generated.deepcopy.go
• payload-manifests/crds/0000_80_machine-config_01_internalreleaseimages-DevPreviewNoUpgrade.crd.yaml
• machineconfiguration/v1alpha1/zz_generated.featuregated-crd-manifests/internalreleaseimages.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml
• machineconfiguration/v1/zz_generated.deepcopy.go
• machineconfiguration/v1/zz_generated.swagger_doc_generated.go
• payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-CustomNoUpgrade.crd.yaml
• payload-manifests/crds/0000_80_machine-config_01_internalreleaseimages-TechPreviewNoUpgrade.crd.yaml
• machineconfiguration/v1/zz_generated.featuregated-crd-manifests.yaml
• machineconfiguration/v1alpha1/zz_generated.swagger_doc_generated.go
• machineconfiguration/v1/tests/machineconfignodes.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml
• machineconfiguration/v1alpha1/zz_generated.crd-manifests/0000_80_machine-config_01_internalreleaseimages-DevPreviewNoUpgrade.crd.yaml
• machineconfiguration/v1alpha1/zz_generated.crd-manifests/0000_80_machine-config_01_internalreleaseimages-CustomNoUpgrade.crd.yaml
• openapi/openapi.json

🧬 Code graph analysis (5)

machineconfiguration/v1alpha1/types_internalreleaseimage.go (2)

machineconfiguration/v1alpha1/zz_generated.swagger_doc_generated.go (5)

• InternalReleaseImageSpec (58-60)
• InternalReleaseImageStatus (67-69)
• InternalReleaseImageRef (49-51)
• InternalReleaseImageBundleStatus (31-33)
• InternalReleaseImage (21-23)

machineconfiguration/v1/types_machineconfignode.go (1)

• InternalReleaseImageConditionType (227-227)

machineconfiguration/v1alpha1/zz_generated.deepcopy.go (2)

machineconfiguration/v1alpha1/types_internalreleaseimage.go (6)

• InternalReleaseImage (25-40)
• InternalReleaseImageBundleStatus (84-121)
• InternalReleaseImageList (152-160)
• InternalReleaseImageRef (58-66)
• InternalReleaseImageSpec (43-54)
• InternalReleaseImageStatus (69-82)

machineconfiguration/v1alpha1/zz_generated.swagger_doc_generated.go (6)

• InternalReleaseImage (21-23)
• InternalReleaseImageBundleStatus (31-33)
• InternalReleaseImageList (40-42)
• InternalReleaseImageRef (49-51)
• InternalReleaseImageSpec (58-60)
• InternalReleaseImageStatus (67-69)

machineconfiguration/v1/zz_generated.deepcopy.go (4)

machineconfiguration/v1alpha1/types_internalreleaseimage.go (1)

• InternalReleaseImage (25-40)

machineconfiguration/v1alpha1/zz_generated.swagger_doc_generated.go (1)

• InternalReleaseImage (21-23)

machineconfiguration/v1/types_machineconfignode.go (2)

• MachineConfigNodeStatusInternalReleaseImage (171-184)
• MachineConfigNodeStatusInternalReleaseImageRef (188-222)

machineconfiguration/v1/zz_generated.swagger_doc_generated.go (2)

• MachineConfigNodeStatusInternalReleaseImage (481-483)
• MachineConfigNodeStatusInternalReleaseImageRef (492-494)

machineconfiguration/v1/zz_generated.swagger_doc_generated.go (1)

machineconfiguration/v1/types_machineconfignode.go (2)

• MachineConfigNodeStatusInternalReleaseImage (171-184)
• MachineConfigNodeStatusInternalReleaseImageRef (188-222)

machineconfiguration/v1alpha1/zz_generated.swagger_doc_generated.go (1)

machineconfiguration/v1alpha1/types_internalreleaseimage.go (6)

• InternalReleaseImage (25-40)
• InternalReleaseImageBundleStatus (84-121)
• InternalReleaseImageList (152-160)
• InternalReleaseImageRef (58-66)
• InternalReleaseImageSpec (43-54)
• InternalReleaseImageStatus (69-82)

🔇 Additional comments (33)

payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-TechPreviewNoUpgrade.crd.yaml (2)

8-8: Verify compatibility level aligns with tech preview feature gate.

The CRD has release.openshift.io/feature-set: TechPreviewNoUpgrade but the description states "Compatibility level 1: Stable". This is contradictory—a tech preview feature cannot carry a stable compatibility guarantee. For a feature behind TechPreviewNoUpgrade, the compatibility statement should indicate alpha/beta status and explain that the API is subject to breaking changes.

Confirm whether the compatibility level should be adjusted (e.g., "Compatibility level 4: Tech Preview are at the alpha level and are subject to breaking changes and removal.") or whether the feature gate annotation is incorrect.

Also applies to: 82-83

---

5-5: Verify API approval annotation.

The api-approved.openshift.io annotation references PR #2255, not the current PR #2510. Please confirm this is the intended approval source for this new feature-gated CRD variant, or update if approval for this specific change is required.

machineconfiguration/v1/zz_generated.featuregated-crd-manifests.yaml (1)

127-127: Feature gate addition looks correct.

Line 127 properly adds NoRegistryClusterInstall to the MachineConfigNode feature gates list, maintaining consistency with existing entries.

payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-Hypershift-CustomNoUpgrade.crd.yaml (2)

355-486: Comprehensive internalReleaseImage field implementation with strong validation.

The new internalReleaseImage field in MachineConfigNode status is well-structured with:

• Proper bounds (1-32 releases)
• Per-release conditions with semantic documentation (Mounted, Installing, Available, Removing, Degraded)
• OCI image reference validation with CEL rules for digest and hostname format
• Release name pattern validation matching expected format

Validations are thorough and align with Kubernetes best practices.

---

625-627: Good use of CEL validation for referential integrity.

The validation rule self.metadata.name == self.spec.node.name enforces that MachineConfigNode name must match the referenced node name, preventing configuration drift.

machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-CustomNoUpgrade.crd.yaml (1)

1-10: Generated CRD artifact.

This file is auto-generated (zz_generated prefix) and mirrors the payload-manifest CRD. No manual edits needed here; generation tooling maintains consistency.

machineconfiguration/v1alpha1/tests/internalreleaseimages.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml (3)

89-146: Semantic issue in "A new mounted release has been discovered" test case.

This test shows a release (ocp-release-bundle-4.19.0-x86_64) appearing in status.releases with a "Mounted" condition, yet it's never added to spec.releases. Given that spec defines the user-desired releases and status is controller-owned, status should only track releases that are in spec.

Either the test should add the release to spec first (showing discovery leads to spec update), or this test case is incorrect. The current semantic suggests the cluster can autonomously add releases to status, which contradicts the API contract.

Can you clarify the intended semantic: should status.releases ever contain a release not listed in spec.releases, or should the test be updated to add the release to spec before it appears in status?

---

78-87: Good: Invalid release name format test case included.

Addresses past feedback requesting additional validation test cases. The regex pattern is properly tested with an invalid format.

---

270-306: Good: Invalid image reference format test case included.

Addresses past feedback requesting validation of image reference format. Test properly validates the CEL rules for OCI image format.

payload-manifests/crds/0000_80_machine-config_01_internalreleaseimages-CustomNoUpgrade.crd.yaml (3)

1-25: Status subresource pattern correctly implemented.

The CRD properly enforces the standard Kubernetes pattern:

• status is NOT required at root level (allows object creation without status)
• status.releases when present requires minItems: 1
• Status subresource enabled for controller updates

This aligns with best practices for controller-owned fields.

---

219-221: Singleton constraint properly enforced.

The CEL validation at the root level correctly enforces that metadata.name must be 'cluster', implementing singleton semantics for this cluster-wide resource.

---

71-74: Release name format validation is appropriate.

The regex pattern ^ocp-release-bundle-[0-9]+\\.[0-9]+\\.[0-9]+-[A-Za-z0-9._-]+$ correctly enforces the semantic versioning format for release bundles and prevents malformed names.

payload-manifests/crds/0000_80_machine-config_01_internalreleaseimages-DevPreviewNoUpgrade.crd.yaml (1)

214-217: Status field correctly omitted from required list.

Following up on prior review feedback, status is properly excluded from the required fields, allowing objects to be created without status and populated later by the controller.

payload-manifests/crds/0000_80_machine-config_01_internalreleaseimages-TechPreviewNoUpgrade.crd.yaml (1)

1-50: Consistent CRD structure across feature gate variants.

This TechPreviewNoUpgrade variant maintains identical schema and validation rules as CustomNoUpgrade and DevPreviewNoUpgrade variants, ensuring consistent API behavior regardless of deployment pathway.

machineconfiguration/v1alpha1/zz_generated.crd-manifests/0000_80_machine-config_01_internalreleaseimages-CustomNoUpgrade.crd.yaml (1)

1-10: Generated CRD artifact - auto-maintained.

This file is auto-generated in the zz_generated.crd-manifests directory. The content correctly reflects the InternalReleaseImage schema with all validations and constraints properly carried through.

machineconfiguration/v1/zz_generated.deepcopy.go (1)

798-835: DeepCopy for InternalReleaseImage status looks correct and consistent

The new DeepCopy implementations for MachineConfigNodeStatus.InternalReleaseImage and its nested types follow the existing patterns (allocate slices, DeepCopy each element) and avoid nil dereferences for the value‑typed field.

Also applies to: 853-897

machineconfiguration/v1alpha1/zz_generated.featuregated-crd-manifests/internalreleaseimages.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml (1)

1-224: CRD schema and feature‑gating for InternalReleaseImage are coherent

Singleton enforcement, spec/status releases constraints, and condition/image validations are all consistent with the v1alpha1 type comments and with the NoRegistryClusterInstall feature‑gate usage. No issues from an API/validation perspective.

machineconfiguration/v1/tests/machineconfignodes.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml (1)

1-87: Status test for internalReleaseImage matches CRD expectations

The onUpdate test populates status.internalReleaseImage.releases with a valid entry (conditions, image, name), so it should exercise the new schema correctly and catch regressions in the CRD or type wiring.

payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-DevPreviewNoUpgrade.crd.yaml (1)

355-486: internalReleaseImage status schema is consistent with the Go types

The new status.internalReleaseImage block (releases list with per‑release conditions, image, and name) matches the MachineConfigNodeStatusInternalReleaseImage{,Ref} definitions and uses appropriate list‑map annotations and MinItems/MaxItems. Looks correct for the SelfManagedHA DevPreview variant.

machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-TechPreviewNoUpgrade.crd.yaml (1)

355-486: TechPreview CRD mirrors the DevPreview internalReleaseImage status correctly

The status.internalReleaseImage section here is structurally and semantically aligned with the DevPreview CRD and the Go status types, so behavior should be consistent across feature sets.

machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-CustomNoUpgrade.crd.yaml (1)

355-486: CustomNoUpgrade CRD’s internalReleaseImage status matches other variants

The internalReleaseImage status shape (releases list, conditions, image, name, and associated validations) is consistent with the DevPreview/TechPreview CRDs and the backing Go types, so API behavior should be uniform across SelfManagedHA feature sets.

machineconfiguration/v1/types_machineconfignode.go (1)

186-242: Per‑release status struct and condition enum are well‑structured

MachineConfigNodeStatusInternalReleaseImageRef plus InternalReleaseImageConditionType give a clear, per‑bundle status surface (conditions, name, image) with strong validation on identifiers and image pull specs. This matches the CRD schemas and should be straightforward for controllers to consume and emit.

machineconfiguration/v1alpha1/zz_generated.crd-manifests/0000_80_machine-config_01_internalreleaseimages-DevPreviewNoUpgrade.crd.yaml (1)

1-224: DevPreviewNoUpgrade CRD for InternalReleaseImage aligns with the v1alpha1 API

The DevPreviewNoUpgrade CRD defines the same spec/status shape, validations, and singleton constraint as the feature‑gated variant, wired to the appropriate feature‑set annotations. This looks correct and consistent with the v1alpha1 type definitions.

payload-manifests/crds/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-CustomNoUpgrade.crd.yaml (1)

355-486: Well-structured internalReleaseImage status field.

The internalReleaseImage field is well-designed with:

• Clear documentation of when release content can be safely pulled (Available=True, Degraded=False)
• Appropriate validation constraints (1-32 releases, 1-5 conditions per release)
• Comprehensive OCI image format validation
• Proper uniqueness enforcement via list map keying on name

The condition types (Mounted, Installing, Available, Removing, Degraded) provide good visibility into the release lifecycle.

machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-Hypershift-Default.crd.yaml (1)

1-383: Generated CRD manifest looks correct.

This Hypershift-Default CRD manifest correctly excludes the internalReleaseImage field (which is behind the NoRegistryClusterInstall feature gate) and maintains the standard MachineConfigNode schema with appropriate validations.

machineconfiguration/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfignodes-SelfManagedHA-DevPreviewNoUpgrade.crd.yaml (1)

355-486: Consistent internalReleaseImage implementation.

The internalReleaseImage field in this DevPreviewNoUpgrade variant is consistent with the CustomNoUpgrade variant, with identical structure, validations, and documentation.

machineconfiguration/v1/zz_generated.featuregated-crd-manifests/machineconfignodes.machineconfiguration.openshift.io/NoRegistryClusterInstall.yaml (1)

1-516: Correct feature-gated CRD manifest.

This manifest correctly applies the NoRegistryClusterInstall feature gate (line 9) and includes the internalReleaseImage field consistently with other feature-gated variants.

openapi/generated_openapi/zz_generated.openapi.go (2)

854-859: New OpenAPI registrations for InternalReleaseImage types look correct

The added entries cleanly register all six InternalReleaseImage* schemas and match the usual pattern used elsewhere in this map. No issues from a correctness or maintainability standpoint.

---

43371-43521: Overall schema structure for InternalReleaseImage resources is consistent with Kubernetes patterns

The object/list/spec/status/ref schemas follow the standard Kube API conventions (kind/apiVersion/metadata, required spec, list items referencing the resource type, and appropriate dependencies). Aside from validation concerns called out separately, the generated OpenAPI wiring here looks sound.

machineconfiguration/v1/zz_generated.swagger_doc_generated.go (1)

459-459: LGTM! Auto-generated Swagger documentation is complete and accurate.

The generated SwaggerDoc mappings for the new InternalReleaseImage-related types are consistent with the type definitions and follow the established patterns in this file.

Also applies to: 476-494

machineconfiguration/v1alpha1/zz_generated.deepcopy.go (1)

13-155: LGTM! Auto-generated DeepCopy implementations are correct and complete.

The generated DeepCopy methods properly handle all nested slices and follow Kubernetes conventions. The InternalReleaseImageBundleStatus correctly performs element-wise deep copying for the Conditions slice, and the InternalReleaseImageStatus properly handles the nested InternalReleaseImageBundleStatus slice.

machineconfiguration/v1alpha1/zz_generated.swagger_doc_generated.go (1)

14-69: LGTM! Auto-generated Swagger documentation for InternalReleaseImage is complete and accurate.

The generated SwaggerDoc mappings comprehensively cover all InternalReleaseImage-related types and properly document the v1alpha1 compatibility level (level 4). The documentation strings are clear and match the type definitions.

openapi/openapi.json (1)

30891-30895: Verify this hunk is intentional for this PR.

The closedClientConnectionPolicy addition to IngressController (line 30891) appears unrelated to the InternalReleaseImage CRD changes described in the PR objectives and AI summary. Confirm whether this change should be included in this PR or if it was inadvertently merged.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Resolve Spec field linter failure.

Per PR comments, kube-apilinter is failing because Spec is a value type with omitzero, but the linter cannot verify that the zero value is invalid. Although Spec.Releases is marked +required with MinItems=1, the linter still requires either:

1. Change Spec to a pointer: *InternalReleaseImageSpec, OR
2. Ensure validation makes spec: {} invalid (e.g., add MinProperties at the Spec level)

This is a blocker that must be resolved before merge.

Based on past review comments flagging this as critical.

🤖 Prompt for AI Agents

In machineconfiguration/v1alpha1/types_internalreleaseimage.go around line 35,
the Spec field uses a value type with `omitzero` which the kube-apilinter flags;
change the field to a pointer type (e.g., Spec *InternalReleaseImageSpec) and
update the JSON tag to `json:"spec,omitempty"` so that an empty spec is clearly
nil, or alternatively add a validation marker on the Spec type such as
`+kubebuilder:validation:MinProperties=1` to make an empty object invalid;
implement one of these fixes consistently and regenerate any generated code if
applicable.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical: Resolve Status field linter failure.

Similar to the Spec field, Status is a value type with omitzero, but contains a required Releases field with MinItems=1. The linter may fail on this as well. Consider:

1. Change to pointer: *InternalReleaseImageStatus, OR
2. Add validation to make status: {} invalid

Verify that the linter passes for the Status field, or apply the same fix used for Spec.

Based on similar pattern to the Spec field issue.

🤖 Prompt for AI Agents

In machineconfiguration/v1alpha1/types_internalreleaseimage.go around line 39,
the Status field is currently a value type declared as "Status
InternalReleaseImageStatus `json:\"status,omitempty,omitzero\"`" but contains a
required Releases array (MinItems=1) which causes the linter to fail; fix by
matching the Spec-field solution: change the field to a pointer type
"*InternalReleaseImageStatus" so omitzero behavior is safe, or alternatively add
explicit validation to disallow an empty status object (make "status: {}"
invalid); apply the same change you used for Spec (prefer pointer) and run the
linter to verify the failure is resolved.

[everettraven]

/lgtm
/override ci/prow/lint

[openshift-ci-robot]

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: everettraven

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:

• OWNERS [everettraven]

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

[openshift-ci]

@everettraven: Overrode contexts on behalf of everettraven: ci/prow/lint

In response to this:

/lgtm
/override ci/prow/lint

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.

[andfasano]

/verified later @andfasano

[openshift-ci-robot]

@andfasano: This PR has been marked to be verified later by @andfasano.

In response to this:

/verified later @andfasano

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.