OKD: Switch to using Centos Stream base container images #1575
Conversation
sdodson
force-pushed
the
okd-centos-userspace
branch
from
6d4a1d6
to
df21104
Compare
|
/lgtm |
Is this still holds true? |
There was a problem hiding this comment.
This needs describe new responsibilities on community / engineers / whoever wants to pick up the task of making new base images, adding PRs to add them to the repos and keeping release repo updated along with triaging if the bug comes from CentOS Stream or also applies to OCP
|
I think the commitment becomes the need to go ensure that all packages necessary are available in Centos Stream. Beyond that I don't envision there being significant burden on engineers. |
|
Apart from ensuring packages and versions available in CentOS Stream each teams need to maintain at least:
|
|
It seems like consensus is that there will definitely be a huge cost to switch. The ongoing steady state build pipeline seems like we can manage. The cost will be for anyone who wants to add a new package to OpenShift that's not readily available in Centos Stream or substantially different from that which is available as part of RHEL. OVS coming from RHEL Fast Data Path being substantially ahead of whatever version of openvswitch is available in either Centos Stream or CBS would be a potential example, though it does seem like openvswitch3.2 is readily available in CBS today. I'm not sure if this belongs in the enhancement or if the comment here is sufficient. |
|
@vrutkovs what else do we need to do before we approve this? |
|
I'd recommend running this enhancement on nearest arch meeting, adding approvers meanwhile: |
| @@ -78,7 +78,7 @@ This is a proposal to: | |||
| ### Graduation Criteria | |||
|
|
|||
| - [x] [OKD repository](https://github.com/openshift/okd/) exists for community issue and bug triage, and development tracking. | |||
| - [x] The UBI-based container images for all components in the release payload are shared between OKD and OCP for testing in Prow (with a few exceptions, see below) | |||
| - [ ] Container images for all components in the release payload are built atop Centos Stream base images most closely matching the majority of OCP images (as of Feb 2024, CS9) and do not contain any content from RHEL builds of any packages. | |||
There was a problem hiding this comment.
We should add ideas how to enforce it - periodics which can list RPMs and image metadata to prevent the leaks happening again?
RHEL builds of any packages
I agree on the idea, but I'd prefer the base idea to still be UBI so that the diff would be minimal and we'd have less OKD-specific issues caused by possible "current RHEL" <-> CentOS Stream disrepancies
There was a problem hiding this comment.
Your motivations for using UBI (stated offline), to maintain bug-for-bug compatibility with OCP, so that Red Hat engineers cannot ignore an OKD bug, cannot be met without including RHEL content which cannot be redistributed. While we could use UBI as the base but Centos Stream for everything else I don't understand the value that provides given it'll never be bug-for-bug compatible. I would like to move forward with this PR since UBI is not valuable or viable.
I agree that we should seek to reduce duplicate efforts of maintenance and I have confidence that work is in progress. I'd like to move forward with this PR as is today.
There was a problem hiding this comment.
While we could use UBI as the base but Centos Stream for everything else I don't understand the value that provides given it'll never be bug-for-bug compatible
I don't mind CentOS Stream used as base. Perhaps using UBI instead would make devs more comfortable with it, but I suppose we can reach an agreement on this.
However its vital to use the same OCP builder if possible/legal - this would help with developer trust (binaries being built with the same compiler as OCP CI) and avoid a costly double rebuild for OKD binaries
There was a problem hiding this comment.
This still needs to list who's responsible for generating C9S-based images - I'd prefer for this to happen transparently on ART side if possible
There was a problem hiding this comment.
We cannot use the same builder image as we want the community to write and submit patches, which require them to be able to build. The OCP Builder images have the same restrictions and we can not make them available.
There was a problem hiding this comment.
@vrutkovs please take a look at the new changes I pushed
There was a problem hiding this comment.
We cannot use the same builder image as we want the community to write and submit patches
Community can use a CentOS9 builder, it doesn't have to be bit-to-bit identical to the builder we use in Prow. This would allow us to use less resources when OKD is being built on Prow and ensure that developers are not burdened with triaging CentOS9 Stream compiler bugs
|
Until we have removed RHEL from OKD we can not ship any more OKD releases. It is in our and the community's interests to quickly resolve the issues so we can get OKD working again. It was communicated to the community on February 6th in the Community call https://www.youtube.com/watch?v=P3A1oe3hf0Y |
Because OpenShift depends on many packages not part of UBI redistributable content we cannot use RHEL UBI as the base image. Thankfully Centos Stream should be fully compatible, so lets use that instead.
sdodson
force-pushed
the
okd-centos-userspace
branch
from
c569cce
to
a53b732
Compare
| @@ -78,7 +78,7 @@ This is a proposal to: | |||
| ### Graduation Criteria | |||
|
|
|||
| - [x] [OKD repository](https://github.com/openshift/okd/) exists for community issue and bug triage, and development tracking. | |||
| - [x] The UBI-based container images for all components in the release payload are shared between OKD and OCP for testing in Prow (with a few exceptions, see below) | |||
| - [ ] Container images for all components used to build or in the release payload are built atop Centos Stream base images most closely matching the majority of OCP images (as of Feb 2024, CS9) and do not contain any content from RHEL builds of any packages. Base images and builders will be maintained jointly by OKD and ART teams. OCP Engineering teams will be responsible for addressing bugs reported against OKD in their individual images but should otherwise have minimal steady state image maintenance burden, adding of net new packages will be required of the team adding those packages however. | |||
There was a problem hiding this comment.
OCP Engineering teams will be responsible for addressing bugs reported against OKD
Who's responsible for triaging OKD bugs - both in Jira and in github issues?
There was a problem hiding this comment.
do not contain any content from RHEL builds of any packages
How are we planning to enforce that? There is nothing preventing devs from using internal RPM repos
There was a problem hiding this comment.
I think Github would need to be triaged first by OKD team/volunteers and if necessary OCPBUGS filed. They're just OCP bugs then so they'd be triaged by all the normal teams.
As to enforcement of no RHEL content that will depend on the implementation path chosen.
|
@sdodson: all tests passed! 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/test-infra repository. I understand the commands that are listed here. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dhellmann 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:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
Because OpenShift depends on many packages not part of UBI redistributable
content we cannot use RHEL UBI as the base image. Thankfully Centos Stream
should be fully compatible, so lets use that instead.
/cc @LorbusChris @vrutkovs