Bug 1679900
Summary: | Cli imagestreams under openshift should be installed after samples-registry-credentials secret create | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | XiuJuan Wang <xiuwang> |
Component: | ImageStreams | Assignee: | Gabe Montero <gmontero> |
Status: | CLOSED ERRATA | QA Contact: | XiuJuan Wang <xiuwang> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.1.0 | CC: | aos-bugs, bparees, jokerman, mmccomas, wzheng |
Target Milestone: | --- | ||
Target Release: | 4.1.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | No Doc Update | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-06-04 10:44:19 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
XiuJuan Wang
2019-02-22 08:10:38 UTC
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 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 |