Description of problem: After install cluster, the cli, tests, installer imagestreams which are not managed by samples operator need import manually due to 'Import failed (Unauthorized)'. Since the three imagestreams installed earlier than samples-operator did, then the samples-registry-credentials secret creates later than those imagestreams. 0000_70_cluster-samples-operator_06-openshift-imagestreams.yaml 0000_70_cluster-samples-operator_07-operator.yaml Version-Release number of selected component (if applicable): $oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-02-21-215247 True False 3h28m 4.0.0-0.nightly-2019-02-21-215247 registry.svc.ci.openshift.org/ocp/release:4.0.0-0.nightly-2019-02-21-215247 How reproducible: always Steps to Reproduce: 1.Check cli, tests,installer imagestreams under openshift project 2. 3. Actual results: $ oc get is -n openshift NAME IMAGE REPOSITORY TAGS UPDATED cli image-registry.openshift-image-registry.svc:5000/openshift/cli latest installer image-registry.openshift-image-registry.svc:5000/openshift/installer latest tests image-registry.openshift-image-registry.svc:5000/openshift/tests latest $ oc describe is cli -n openshift Name: cli Namespace: openshift Created: 4 hours ago Labels: <none> Annotations: <none> Image Repository: image-registry.openshift-image-registry.svc:5000/openshift/cli Image Lookup: local=false Unique Images: 0 Tags: 1 latest tagged from quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:3ad0df04f953c4f8ceedea0986ca4f47091389783c5764f9178c27360783c1ef ! error: Import failed (Unauthorized): you may not have access to the Docker image "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:3ad0df04f953c4f8ceedea0986ca4f47091389783c5764f9178c27360783c1ef" 4 hours ago Expected results: cli, tests,installer imagestreams should be imported successfully after install cluster. Additional info:
Gabe, in theory i think moving those imagestreams later in the manifest than the clusteroperator object itself might make this work (assuming the samples operator's clusteroperator status does not report available=true until the secret has been copied over). In practice, I think this means we ought to make these additional imagestreams a first class part of the samples operator managed bits at some point, but that means treating them like jenkins (ie all the special casing we do for jenkins to substitute the pullspec and not let the registry hostname be overwritten). So probably go w/ the short term fix if you agree it should work.
Ben: 1) Yes, we will not attempt to create the samples until the secret is copied over. So available==false until we finish creating all the samples 2) Moving those imagestreams later in the manifest .... I could not find where those imagestreams are defined, so don't know how to move them. I guessed it was buried in https://github.com/openshift/release somewhere but could not find it. Plus, I looked at a release-payload, and the clusteroperator object is listed way way early (20th in that big long list). On long term making them first class citizens wrt samples operator ... yeah, even though the jenkins* are in the payload, they are also defined in openshift/library, so that makes the special casing fairly limited. The Clayton specials like "cli" are of course not defined there. Nor should be I would think. The special casing for those will have additional hits. I'm more inclined to just have whatever early installer code that places the pull secret in kube-system also place it in the openshift namespace, and keep the samples operator out of it, assuming these Clayton specials need to be healthy out of the gate. We would still monitor kube-system (or whatever the final landing spot might be) for changes and recreates in the openshift namespace. Thoughts?
Having the installer put the pullsecret into the openshift namespace is a reasonable solution to me, definitely worth talking to them about, but there may be pushback so i'd reorder the manifests in the short term.
OK Ben showed me that those imagestreams were being defined under my own nose in the cluster-samples-operator manifests :-) Still have the same opinion against the "long term fix / first class citizenship" But nix the notion of having the installer direcly store the coreos pull secret into the openshift namespace
PR https://github.com/openshift/cluster-samples-operator/pull/112 is up
PR has merged
Thanks gabe， The cli, installer, tests imagestreams could be imported automaticlly after install cluster. $ oc get is cli tests installer -n openshift NAME IMAGE REPOSITORY TAGS UPDATED cli image-registry.openshift-image-registry.svc:5000/openshift/cli latest 7 hours ago NAME IMAGE REPOSITORY TAGS UPDATED tests image-registry.openshift-image-registry.svc:5000/openshift/tests latest 7 hours ago NAME IMAGE REPOSITORY TAGS UPDATED installer image-registry.openshift-image-registry.svc:5000/openshift/installer latest 7 hours ago $oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.0.0-0.nightly-2019-02-25-194625 True False 7h9m Cluster version is 4.0.0-0.nightly-2019-02-25-194625
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:0758