Description of problem: Image machine-os-content in payload quay.io/openshift-release-dev/ocp-release:4.0.0-0.2 is from registry.svc.ci.openshift.org, while the others are from quay.io Version-Release number of the following components: quay.io/openshift-release-dev/ocp-release:4.0.0-0.2 quay.io/openshift-release-dev/ocp-release@sha256:8580a118ce951dd241e4a4b73a0e5f4cda3b56088b6c1ab56ccadbf8e270fb1d How reproducible: Always Steps to Reproduce: $ oc adm release info quay.io/openshift-release-dev/ocp-release:4.0.0-0.2 --pull-specs Actual results: $ oc adm release info quay.io/openshift-release-dev/ocp-release:4.0.0-0.2 --pullspecs | grep registry.svc libvirt-machine-controllers registry.svc.ci.openshift.org/ocp/4.0-art-latest-2019-01-25-205123@sha256:8b848ebe6ba72a678300a0fa9b7749bcef3b4230e355e1c789527e6d1c615225 machine-os-content registry.svc.ci.openshift.org/ocp/4.0-art-latest-2019-01-25-205123@sha256:61dc83d62cfb5054c4c5532bd2478742a0711075ef5151572e63f94babeacc1a Expected results: Image machine-os-content is from quay.io as the other images do.
`machine-os-content` is Red Hat Enterprise Linux CoreOS. Today that "oscontainer" comes out of the RHCOS build system. The RHCOS team is in progress of helping ART own a copy of the buildsystem. ART should own pushing updates of `machine-os-content` for OCP 4.0.
(In reply to Liang Xia from comment #0) > Description of problem: > Image machine-os-content in payload > quay.io/openshift-release-dev/ocp-release:4.0.0-0.2 is from > registry.svc.ci.openshift.org, while the others are from quay.io > > > Version-Release number of the following components: > quay.io/openshift-release-dev/ocp-release:4.0.0-0.2 > quay.io/openshift-release-dev/ocp-release@sha256: > 8580a118ce951dd241e4a4b73a0e5f4cda3b56088b6c1ab56ccadbf8e270fb1d > > > Expected results: > Image machine-os-content is from quay.io as the other images do. @Liang, You're correct, those images *should* be coming from quay.io. However, following what Colin responded with, that is not currently the case. The build and delivery of this image is in the process of being *transitioned* to ARTs ownership and operation. Due to this fact the machine-os-content image must necessarily come from registry.svc.ci until such a time that ART is building and delivering that image ourselves. I am going to leave this bug in an open state for the time being. When we have taken full ownership of the RHCOS delivery pipeline we will revisit this bug and provide an update. Let me know if that doesn't work for you and we can look at alternatives.
Putting this in POST state because "the fix" is ART having an operational RHCOS pipeline and "being merged" is ART is delivering this image and adding it to the payload automatically.
...... > I am going to leave this bug in an open state for the time being. When we > have taken full ownership of the RHCOS delivery pipeline we will revisit > this bug and provide an update. > > Let me know if that doesn't work for you and we can look at alternatives. I'm OK with that.
@Luke, we'll want to review this soon.
*** This bug has been marked as a duplicate of bug 1690823 ***