Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

publish okd-os base image in the same place as release image #13

Open
cgwalters opened this issue Sep 22, 2022 · 5 comments
Open

publish okd-os base image in the same place as release image #13

cgwalters opened this issue Sep 22, 2022 · 5 comments

Comments

@cgwalters
Copy link

This is the same issue as https://issues.redhat.com/browse/ART-4352 which is for RHCOS.

Basically AFAICS today OKD builds a custom image derived from FCOS. Let's publish that image in a convenient place external to the release image so it can be used in external container builds, like https://github.com/coreos/coreos-layering-examples

@LorbusChris
Copy link
Contributor

registry.ci.openshift.org/origin/4.12:fedora-coreos exists today internally, we should publish that to quay, maybe tagged with the FCOS version it is derived from

@cgwalters
Copy link
Author

OK cool, yeah that's a fine start though. I do think as argued in the ART ticket for RHCOS we want something more like

Images tagged corresponding to the published stable cluster versions (like the nicer OCP 4.11.7, 4.11.8) style

  • quay.io/okd/fedora-coreos-node:4.11.0-0.okd-2022-08-20-022919
  • quay.io/okd/fedora-coreos-node:4.11.0-0.okd-2022-07-29-154152

Floating tags:

  • quay.io/okd/fedora-coreos-node:4.11
  • quay.io/okd/fedora-coreos-node:4.12.nightly # tracks the latest accepted 4.12 nightly

or so?

@LorbusChris
Copy link
Contributor

that's totally fine with me too!

@cgwalters
Copy link
Author

Of course...one notable thing here that OKD has glossed over but will now become more prominent is that this versioning scheme hides the version of FCOS. It is its own big topic, obviously Fedora CoreOS was intentionally designed to be a "floating" system.

However, for RHEL CoreOS (and CentOS) I think the version number is...kind of important. And particularly the major version. This is one reason why I've pushed to have it be rhel-coreos-8 and rhel-coreos-9.

But even then, ISTM we probably want to do something useful with the container version tag here. We could do what RHCOS does and just prepend the OKD version and end up with

version=4.11.36.20220921.20.0 perhaps?

@cgwalters
Copy link
Author

Veering off topic a bit more but it still related so just interesting to note that we also have two different git source schemas in this derived container:

$ skopeo inspect -n --no-creds docker://registry.ci.openshift.org/origin/4.12:fedora-coreos
...
        "io.openshift.build.source-location": "https://github.com/openshift/okd-machine-os",
        "io.openshift.build.version-display-names": "machine-os=Fedora CoreOS",
        "io.openshift.build.versions": "machine-os=36.20220921.20",
        "io.openshift.release.operator": "true",
        "org.opencontainers.image.revision": "e9ea2831f41bfb5456312774ba79649b1d2c25e1",
        "org.opencontainers.image.source": "https://github.com/coreos/fedora-coreos-config",
        "vcs-ref": "07d1476897be28b56f77438ebd2c14d316fef427",
        "vcs-type": "git",
        "vcs-url": "https://github.com/openshift/okd-machine-os",

This is because OCP builds use io.openshift schema, whereas coreos-assembler we intentionally chose to use the OCI standard annotations for this.

It's interesting because it's not actually wrong but it is a bit confusing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants