Please drop machine-os-content reference

[cgwalters]

xref openshift/machine-config-operator#3364
https://issues.redhat.com/browse/MCO-392?focusedCommentId=21045301&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-21045301

[qbarrand]

Reopening this issue with #103.
We need more guidance on how to replace machine-os-content, which provides an essential piece in the way DTK is currently released.

[qbarrand]

/reopen

[openshift-ci]

@qbarrand: Reopened this issue.

In response to this:

/reopen

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.

[cgwalters]

OK, let's discuss design in https://issues.redhat.com/browse/MCO-392?focusedCommentId=21048335&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-21048335 or so? I see the desire for a tag for "default operating system". But I'd still really like to push for a world where we ship both rhel-coreos-8 and rhel-coreos-9 for example, and so anything using the "default" tag would then need to consider whether it actually needs to look at all possible operating system tags for example.

[ybettan]

/cc @ybettan
So I can keep track of it.

[ybettan]

I have added documentation of all the moving parts of that imagestream.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[ybettan]

/remove-lifecycle stale
After some discussion the first step of the solution will be to try to user rhel-coreos-8 or rhel-coreos-9 in the image-refrences instead of machine-os-content.

This will require adding the io.openshift.build.versions label to the rhel-coreos-<8|9> and replace the primary source in ART's repo.

Additional info can be found at https://redhat-internal.slack.com/archives/C02CU30L7GF/p1676467754327349

[ybettan]

/assign @ybettan

[sosiouxme]

it's just rhel-coreos now. but io.openshift.build.versions label isn't there like in m-o-c:

🐚 oc image info $(oc adm release info --image-for rhel-coreos 4.13.0-rc.5) | grep version
            org.opencontainers.image.version=413.92.202304191831-0
            version=413.92.202304191831-0
            
🐚 oc image info $(oc adm release info --image-for machine-os-content 4.13.0-rc.5) | grep versions
             io.openshift.build.versions=machine-os=413.92.202304191831-0

[cgwalters]

Yeah, this is messy...there's a whole lot interlocked here. We have a build time option to add it and I tried to use it here but then we reverted here because we discovered that oc adm release new barfs if there are two images with the same machine-os label...

And that's where it stands, I think we'd need to fix oc adm release new.

[sosiouxme]

perhaps DTK could change to looking at org.opencontainers.image.version label for 4.13+?
not sure the significance of these labels

[ybettan]

@sosiouxme DTK isn't doing any of this stuff at all.
All we are doing is to add the machine-os-content snapshot.

I think that oc adm new... is the one responsible for the substitution so this change will probably need to be done there.

I don't mind changing the shapshot to any other container if needed to make it work.

Adding the slack thread for full context if needed: https://redhat-internal.slack.com/archives/C02CU30L7GF/p1676467754327349

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[ybettan]

/remove-lifecycle stale

[jlebon]

The RHCOS pipeline is still building and maintaining the path to this container image. Would be helpful if we could finally nuke it completely from our deliverables. (E.g. our pipeline just tripped on a bug trying to build that container: coreos/coreos-assembler#3635).

Naive question: rather than trying to solve the "how to ship multiple images with proper labels" part (which requires changes to oc), can we not stage the changes in both RHCOS and DTK and flip the switch roughly at the same time so that the new container has machine-os and the old container is gone?

It sounds like the blocker was on the fact that we'll eventually want the oc changes anyway so that we can ship multiple OS versions in the future, but it seems like for now we don't have to block on that to remove the legacy oscontainer.

[ybettan]

Naive question: rather than trying to solve the "how to ship multiple images with proper labels" part (which requires changes to oc), can we not stage the changes in both RHCOS and DTK and flip the switch roughly at the same time so that the new container has machine-os and the old container is gone?

I don't anticipate an issue from the DTK side doing it.
AFAIK, if:

1. machine-oc-content is removed
2. "io.openshift.build.versions": "machine-os=<ocp version>.<rhel version>.<timestamp>" is added to rhel-coreos instead
3. dtk-image-references is modified to point to rhel-coreos image instead of machine-os-content
   Then we should be good to go.

In case the io.openshift.build.versions needs to be added to any other container in the payload in the future, then we can address the oc issue.

[jlebon]

I threw up openshift/os#1374 and #135. I invite folks who have more context on this issue to review those. On the ART side, it looks like https://issues.redhat.com/browse/ART-4932 is still the ticket tracking the cleanups needed there.