OCPBUGS-87461: Updating cluster-version-operator-container image to be consistent with ART for 5.0#1400
Conversation
openshift-bot
force-pushed
the
art-consistency-openshift-5.0-cluster-version-operator
branch
from
07f0e21 to
9017b35
Compare
|
Created by ART pipeline job run https://art-jenkins.apps.prod-stable-spoke1-dc-iad2.itup.redhat.com/job/aos-cd-builds/job/build%252Fsync-ci-images/216 |
WalkthroughThis PR updates base container images for the cluster-version-operator across CI build configuration and Dockerfile build stages. The build root, builder stage, and final runtime stage are all upgraded to use Go 1.26 with OpenShift 5.0, and the final runtime base moves from OpenShift 4.22 RHEL9 minimal to OpenShift 5.0 RHEL9. ChangesBase Image Version Upgrade
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error, 1 warning)
✅ Passed checks (13 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
openshift-bot
changed the title
openshift-ci-robot
added
jira/valid-reference
|
@openshift-bot: This pull request references Jira Issue OCPBUGS-87461, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: openshift-bot The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@openshift-bot: This pull request references Jira Issue OCPBUGS-87461, which is valid. 3 validation(s) were run on this bug
DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
Dockerfile.rhel (2)
1-15: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick winAdd HEALTHCHECK directive for container health monitoring.
No
HEALTHCHECKis defined. As per coding guidelines, "HEALTHCHECK defined" is required for production containers. Without a healthcheck, orchestrators cannot distinguish between a running-but-unhealthy container and a healthy one, reducing observability and resilience.🏥 Proposed HEALTHCHECK addition
Add a
HEALTHCHECKdirective appropriate for CVO. For example, if CVO exposes a health endpoint:COPY bootstrap /bootstrap +HEALTHCHECK --interval=30s --timeout=5s --start-period=60s --retries=3 \ + CMD ["/usr/bin/cluster-version-operator", "healthcheck"] || exit 1 USER 1001 ENTRYPOINT ["/usr/bin/cluster-version-operator"]If CVO does not have a built-in healthcheck command, consider adding one or using a process-check approach. Verify the appropriate healthcheck mechanism for CVO.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile.rhel` around lines 1 - 15, The Dockerfile is missing a HEALTHCHECK directive; add a HEALTHCHECK instruction after the ENTRYPOINT (or before finalizing the image) that verifies the cluster-version-operator process is healthy (for example by curling its HTTP health endpoint if one exists, or by running a small script that checks the /usr/bin/cluster-version-operator process is alive and responsive); if no built-in health endpoint exists, add a lightweight healthcheck script in the image (referencing /usr/bin/cluster-version-operator and any health port/path) and invoke that script from HEALTHCHECK so orchestrators can detect unhealthy containers.Source: Coding guidelines
1-15:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winContainer runs as root - add USER directive.
No
USERdirective is defined, so the container runs as root (UID 0). As per coding guidelines, "USER non-root; never run as root." Running as root violates least-privilege principles and increases the attack surface if the container is compromised.🛡️ Proposed fix to add non-root user
Add a
USERdirective before theENTRYPOINT:COPY bootstrap /bootstrap +USER 1001 ENTRYPOINT ["/usr/bin/cluster-version-operator"]Verify that the CVO deployment manifests in
install/specify the same UID in the pod security context, or ensure the runtime base image already defines a suitable non-root user.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile.rhel` around lines 1 - 15, The Dockerfile currently leaves the image running as root (no USER) — add a non-root user directive before ENTRYPOINT (e.g., USER <nonroot> or USER <uid>:<gid>) and ensure it matches any PodSecurityContext in install/; adjust file ownership/permissions for /usr/bin/cluster-version-operator, /manifests and /bootstrap (chown/chmod during the builder stage or in the final image) so the chosen non-root user can execute/read them; verify whether the base image already provides a non-root user (and use that numeric UID if so) and keep the ENTRYPOINT ["/usr/bin/cluster-version-operator"] unchanged.Sources: Coding guidelines, Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Dockerfile.rhel`:
- Line 8: The FROM line in Dockerfile.rhel was changed to a non-minimal image
(registry.ci.openshift.org/ocp/5.0:base-rhel9) which increases footprint; update
the Dockerfile.rhel FROM instruction to use the minimal UBI variant
(registry.ci.openshift.org/ocp/5.0:base-rhel9-minimal) to comply with the "UBI
minimal or distroless" guideline, or if OpenShift ART requires the non-minimal
variant, add a short comment and documentation entry explaining why base-rhel9
is required and who approved it so the change is intentional and auditable.
---
Outside diff comments:
In `@Dockerfile.rhel`:
- Around line 1-15: The Dockerfile is missing a HEALTHCHECK directive; add a
HEALTHCHECK instruction after the ENTRYPOINT (or before finalizing the image)
that verifies the cluster-version-operator process is healthy (for example by
curling its HTTP health endpoint if one exists, or by running a small script
that checks the /usr/bin/cluster-version-operator process is alive and
responsive); if no built-in health endpoint exists, add a lightweight
healthcheck script in the image (referencing /usr/bin/cluster-version-operator
and any health port/path) and invoke that script from HEALTHCHECK so
orchestrators can detect unhealthy containers.
- Around line 1-15: The Dockerfile currently leaves the image running as root
(no USER) — add a non-root user directive before ENTRYPOINT (e.g., USER
<nonroot> or USER <uid>:<gid>) and ensure it matches any PodSecurityContext in
install/; adjust file ownership/permissions for
/usr/bin/cluster-version-operator, /manifests and /bootstrap (chown/chmod during
the builder stage or in the final image) so the chosen non-root user can
execute/read them; verify whether the base image already provides a non-root
user (and use that numeric UID if so) and keep the ENTRYPOINT
["/usr/bin/cluster-version-operator"] unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 8ca267fc-5a69-413a-9fc9-e57dfa6ddc63
📒 Files selected for processing (2)
.ci-operator.yamlDockerfile.rhel
| cp _output/linux/$(go env GOARCH)/cluster-version-operator _output/linux/$(go env GOARCH)/cluster-version-operator-tests.gz /tmp/build/ | ||
|
|
||
| FROM registry.ci.openshift.org/ocp/4.22:base-rhel9-minimal | ||
| FROM registry.ci.openshift.org/ocp/5.0:base-rhel9 |
There was a problem hiding this comment.
Base image regressed from minimal to non-minimal variant.
The runtime base changed from base-rhel9-minimal to base-rhel9, moving away from the minimal variant. As per coding guidelines, container base images should be "UBI minimal or distroless from catalog.redhat.com." While these are OpenShift registry images, the guideline intent is to minimize attack surface and image size. The change increases the container's package footprint and potential vulnerabilities.
If ART requires the non-minimal base for OpenShift 5.0, please confirm this is intentional and document the rationale. Otherwise, consider using registry.ci.openshift.org/ocp/5.0:base-rhel9-minimal if available.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Dockerfile.rhel` at line 8, The FROM line in Dockerfile.rhel was changed to a
non-minimal image (registry.ci.openshift.org/ocp/5.0:base-rhel9) which increases
footprint; update the Dockerfile.rhel FROM instruction to use the minimal UBI
variant (registry.ci.openshift.org/ocp/5.0:base-rhel9-minimal) to comply with
the "UBI minimal or distroless" guideline, or if OpenShift ART requires the
non-minimal variant, add a short comment and documentation entry explaining why
base-rhel9 is required and who approved it so the change is intentional and
auditable.
Source: Coding guidelines
|
@openshift-bot: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
2 participants
Updating cluster-version-operator-container image to be consistent with ART for 5.0
TLDR:
Product builds by ART can be configured for different base and builder images than corresponding CI
builds. This automated PR requests a change to CI configuration to align with ART's configuration;
please take steps to merge it quickly or contact ART to coordinate changes.
The configuration in the following ART component metadata is driving this alignment request:
cluster-version-operator.yml.
Detail:
This repository is out of sync with the downstream product builds for this component. The CI
configuration for at least one image differs from ART's expected product configuration. This should
be addressed to ensure that the component's CI testing accurate reflects what customers will
experience.
Most of these PRs are opened as an ART-driven proposal to migrate base image or builder(s) to a
different version, usually prior to GA. The intent is to effect changes in both configurations
simultaneously without breaking either CI or ART builds, so usually ART builds are configured to
consider CI as canonical and attempt to match CI config until the PR merges to align both. ART may
also configure changes in GA releases with CI remaining canonical for a brief grace period to enable
CI to succeed and the alignment PR to merge. In either case, ART configuration will be made
canonical at some point (typically at branch-cut before GA or release dev-cut after GA), so it is
important to align CI configuration as soon as possible.
PRs are also triggered when CI configuration changes without ART coordination, for instance to
change the number of builder images or to use a different golang version. These changes should be
coordinated with ART; whether ART configuration is canonical or not, preferably it would be updated
first to enable the changes to occur simultaneously in both CI and ART at the same time. This also
gives ART a chance to validate the intended changes first. For instance, ART compiles most
components with the Golang version being used by the control plane for a given OpenShift release.
Exceptions to this convention (i.e. you believe your component must be compiled with a Golang
version independent from the control plane) must be granted by the OpenShift staff engineers and
communicated to the ART team.
Roles & Responsibilities:
tests OR that necessary metadata changes are reported to the ART team
in
#forum-ocp-arton Slack. If necessary, the changes required by this pull request can beintroduced with a separate PR opened by the component team. Once the repository is aligned,
this PR will be closed automatically.
verify-depsis complaining. In that case, please opena new PR with the dependency issues addressed (and base images bumped). ART-9595 for reference.
any required labels to ensure the PR merges once tests are passing. In cases where ART config is
canonical, downstream builds are already being built with these changes, and merging this PR
only improves the fidelity of our CI. In cases where ART config is not canonical, this provides
a grace period for the component team to align their CI with ART's configuration before it becomes
canonical in product builds.
ART has been configured to reconcile your CI build root image (see https://docs.ci.openshift.org/docs/architecture/ci-operator/#build-root-image).
In order for your upstream .ci-operator.yaml configuration to be honored, you must set the following in your openshift/release ci-operator configuration file:
Change behavior of future PRs:
set up automatically. This means that such a PR would merge without human intervention (and awareness!) in the future.
To do so, open a PR to set the
auto_labelattribute in the image configuration. ExampleUPSTREAM: <carry>:. An example.If you have any questions about this pull request, please reach out in the
#forum-ocp-artSlack channel.Summary by CodeRabbit