On Mon, Sep 16, 2019 at 1:18 PM Just Marvin < [email protected]> wrote:
> Ben, Fernando, > > It turns out that saying "no" to the ssh connection prompt causes the > logic to fallback to the normal paths, and then the command works. So many > thanks to getting me to this point. However, the interpretation of the IS > name as a hostname _will_ cause problems for scripts running the command - > so is there a way to turn off that logic? > use the --image-stream parameter instead of the ~ syntax, to point new-app to the imagestream tag you want to use. > > Regards, > Marvin > > On Mon, Sep 16, 2019 at 1:13 PM Just Marvin < > [email protected]> wrote: > >> Fernando, >> >> Thanks for offering a solution. I've run into a different problem >> with your syntax (which, if it weren't happening to me, I'd find hilarious): >> >> [zaphod@oc6010654212 ~]$ oc new-app >> jboss-eap72-openshift:1.0~git@github.<....rest >> of enterprise github ssh url> --name=humongous --source-secret=<github >> secret> >> The authenticity of host 'jboss-eap72-openshift (23.202.231.166)' can't >> be established. >> ECDSA key fingerprint is >> SHA256:HnzBy7BAfkMCT4uIcdLrpoWiOrnhHhN8k7XMbbB2Epk. >> ECDSA key fingerprint is >> MD5:d1:23:b1:96:eb:66:5f:5f:09:64:b9:27:0e:9e:c5:e4. >> Are you sure you want to continue connecting (yes/no)? no >> >> Turns out that from my machine >> >> zaphod@oc6010654212 ~]$ ping jboss-eap72-openshift >> PING jboss-eap72-openshift (23.202.231.166) 56(84) bytes of data. >> 64 bytes from a23-202-231-166.deploy.static.akamaitechnologies.com >> (23.202.231.166): icmp_seq=1 ttl=53 time=27.7 ms >> ^C >> >> and no, there is nothing in /etc/hosts pointing to this. >> >> How do I turn off the oc command interpreting it as a hostname? >> >> Without the version, and with Ben's suggestion of --loglevel=5, I get >> the following output: >> >> [zaphod@oc6010654212 ~]$ oc new-app >> [email protected]:kstephe/humongous-stuff.git >> --name=humongous --source-secret=github-ibm-com-secret --loglevel=5 >> I0916 13:09:46.640833 2277 newapp.go:644] Docker client did not >> respond to a ping: Get http://unix.sock/_ping: dial unix >> /var/run/docker.sock: connect: no such file or directory >> I0916 13:09:46.640936 2277 repository.go:424] Executing git ls-remote >> [email protected]:kstephe/humongous-stuff.git >> I0916 13:09:46.936510 2277 repository.go:492] Error executing command: >> exit status 128 >> I0916 13:09:46.936587 2277 repository.go:424] Executing git ls-remote >> [email protected]:kstephe/humongous-stuff.git >> I0916 13:09:47.205235 2277 repository.go:492] Error executing command: >> exit status 128 >> I0916 13:09:47.205306 2277 repository.go:424] Executing git ls-remote >> [email protected]:kstephe/humongous-stuff.git >> I0916 13:09:48.493636 2277 repository.go:492] Error executing command: >> exit status 128 >> I0916 13:09:48.493735 2277 sourcelookup.go:89] could not list git >> remotes for >> [email protected]:kstephe/humongous-stuff.git: >> Permission denied (publickey). >> fatal: Could not read from remote repository. >> >> Please make sure you have the correct access rights >> and the repository exists. >> I0916 13:09:48.493793 2277 newapp.go:314] treating >> [email protected]:kstephe/humongous-stuff.git as >> a component ref >> I0916 13:09:48.493947 2277 imagestreamlookup.go:64] checking >> ImageStreams jman/jboss-eap72-openshift with ref "latest" >> I0916 13:09:48.512329 2277 imagestreamlookup.go:64] checking >> ImageStreams openshift/jboss-eap72-openshift with ref "latest" >> I0916 13:09:48.532852 2277 imagestreamlookup.go:80] unscored >> apicast-gateway: 1 >> I0916 13:09:48.532888 2277 imagestreamlookup.go:80] unscored >> apicurito-ui: 1 >> I0916 13:09:48.532897 2277 imagestreamlookup.go:80] unscored cli: 1 >> I0916 13:09:48.532906 2277 imagestreamlookup.go:80] unscored >> cli-artifacts: 1 >> I0916 13:09:48.532915 2277 imagestreamlookup.go:80] unscored dotnet: 1 >> I0916 13:09:48.532924 2277 imagestreamlookup.go:80] unscored >> dotnet-runtime: 1 >> I0916 13:09:48.532932 2277 imagestreamlookup.go:80] unscored >> eap-cd-openshift: 1 >> I0916 13:09:48.532942 2277 imagestreamlookup.go:80] unscored >> fis-java-openshift: 1 >> I0916 13:09:48.532952 2277 imagestreamlookup.go:80] unscored >> fis-karaf-openshift: 1 >> I0916 13:09:48.532961 2277 imagestreamlookup.go:80] unscored >> fuse-apicurito-generator: 1 >> I0916 13:09:48.532971 2277 imagestreamlookup.go:80] unscored >> fuse7-console: 1 >> I0916 13:09:48.532979 2277 imagestreamlookup.go:80] unscored >> fuse7-eap-openshift: 1 >> I0916 13:09:48.532989 2277 imagestreamlookup.go:80] unscored >> fuse7-java-openshift: 1 >> I0916 13:09:48.532997 2277 imagestreamlookup.go:80] unscored >> fuse7-karaf-openshift: 1 >> I0916 13:09:48.533007 2277 imagestreamlookup.go:80] unscored httpd: 1 >> I0916 13:09:48.533015 2277 imagestreamlookup.go:80] unscored >> installer: 1 >> I0916 13:09:48.533025 2277 imagestreamlookup.go:80] unscored >> installer-artifacts: 1 >> I0916 13:09:48.533034 2277 imagestreamlookup.go:80] unscored java: 1 >> I0916 13:09:48.533044 2277 imagestreamlookup.go:80] unscored >> jboss-amq-62: 1 >> I0916 13:09:48.533052 2277 imagestreamlookup.go:80] unscored >> jboss-amq-63: 1 >> I0916 13:09:48.533061 2277 imagestreamlookup.go:80] unscored >> jboss-datagrid65-client-openshift: 1 >> I0916 13:09:48.533069 2277 imagestreamlookup.go:80] unscored >> jboss-datagrid65-openshift: 1 >> I0916 13:09:48.533079 2277 imagestreamlookup.go:80] unscored >> jboss-datagrid71-client-openshift: 1 >> I0916 13:09:48.533088 2277 imagestreamlookup.go:80] unscored >> jboss-datagrid71-openshift: 1 >> I0916 13:09:48.533098 2277 imagestreamlookup.go:80] unscored >> jboss-datagrid72-openshift: 1 >> I0916 13:09:48.533107 2277 imagestreamlookup.go:80] unscored >> jboss-datavirt64-driver-openshift: 1 >> I0916 13:09:48.533116 2277 imagestreamlookup.go:80] unscored >> jboss-datavirt64-openshift: 1 >> I0916 13:09:48.533126 2277 imagestreamlookup.go:80] unscored >> jboss-decisionserver64-openshift: 1 >> I0916 13:09:48.533136 2277 imagestreamlookup.go:80] unscored >> jboss-eap64-openshift: 1 >> I0916 13:09:48.533145 2277 imagestreamlookup.go:80] unscored >> jboss-eap70-openshift: 1 >> I0916 13:09:48.533155 2277 imagestreamlookup.go:80] unscored >> jboss-eap71-openshift: 1 >> I0916 13:09:48.533167 2277 imagestreamlookup.go:154] no image recorded >> for openshift/jboss-eap72-openshift:latest >> I0916 13:09:48.533179 2277 imagestreamlookup.go:80] unscored >> jboss-fuse70-console: 1 >> I0916 13:09:48.533189 2277 imagestreamlookup.go:80] unscored >> jboss-fuse70-eap-openshift: 1 >> I0916 13:09:48.533198 2277 imagestreamlookup.go:80] unscored >> jboss-fuse70-java-openshift: 1 >> I0916 13:09:48.533208 2277 imagestreamlookup.go:80] unscored >> jboss-fuse70-karaf-openshift: 1 >> I0916 13:09:48.533217 2277 imagestreamlookup.go:80] unscored >> jboss-processserver64-openshift: 1 >> I0916 13:09:48.533227 2277 imagestreamlookup.go:80] unscored >> jboss-webserver30-tomcat7-openshift: 1 >> I0916 13:09:48.533239 2277 imagestreamlookup.go:80] unscored >> jboss-webserver30-tomcat8-openshift: 1 >> I0916 13:09:48.533249 2277 imagestreamlookup.go:80] unscored >> jboss-webserver31-tomcat7-openshift: 1 >> I0916 13:09:48.533259 2277 imagestreamlookup.go:80] unscored >> jboss-webserver31-tomcat8-openshift: 1 >> I0916 13:09:48.533268 2277 imagestreamlookup.go:80] unscored >> jboss-webserver50-tomcat9-openshift: 1 >> I0916 13:09:48.533277 2277 imagestreamlookup.go:80] unscored jenkins: 1 >> I0916 13:09:48.533287 2277 imagestreamlookup.go:80] unscored >> jenkins-agent-maven: 1 >> I0916 13:09:48.533296 2277 imagestreamlookup.go:80] unscored >> jenkins-agent-nodejs: 1 >> I0916 13:09:48.533305 2277 imagestreamlookup.go:80] unscored mariadb: 1 >> I0916 13:09:48.533314 2277 imagestreamlookup.go:80] unscored >> modern-webapp: 1 >> I0916 13:09:48.533322 2277 imagestreamlookup.go:80] unscored mongodb: 1 >> I0916 13:09:48.533331 2277 imagestreamlookup.go:80] unscored >> must-gather: 1 >> I0916 13:09:48.533340 2277 imagestreamlookup.go:80] unscored mysql: 1 >> I0916 13:09:48.533349 2277 imagestreamlookup.go:80] unscored nginx: 1 >> I0916 13:09:48.533358 2277 imagestreamlookup.go:80] unscored nodejs: 1 >> I0916 13:09:48.533366 2277 imagestreamlookup.go:80] unscored perl: 1 >> I0916 13:09:48.533375 2277 imagestreamlookup.go:80] unscored php: 1 >> I0916 13:09:48.533384 2277 imagestreamlookup.go:80] unscored >> postgresql: 1 >> I0916 13:09:48.533393 2277 imagestreamlookup.go:80] unscored python: 1 >> I0916 13:09:48.533402 2277 imagestreamlookup.go:80] unscored >> redhat-openjdk18-openshift: 1 >> I0916 13:09:48.533411 2277 imagestreamlookup.go:80] unscored >> redhat-sso70-openshift: 1 >> I0916 13:09:48.533421 2277 imagestreamlookup.go:80] unscored >> redhat-sso71-openshift: 1 >> I0916 13:09:48.533429 2277 imagestreamlookup.go:80] unscored >> redhat-sso72-openshift: 1 >> I0916 13:09:48.533439 2277 imagestreamlookup.go:80] unscored >> redhat-sso73-openshift: 1 >> I0916 13:09:48.533449 2277 imagestreamlookup.go:80] unscored redis: 1 >> I0916 13:09:48.533459 2277 imagestreamlookup.go:80] unscored >> rhdm73-decisioncentral-indexing-openshift: 1 >> I0916 13:09:48.533469 2277 imagestreamlookup.go:80] unscored >> rhdm73-decisioncentral-openshift: 1 >> I0916 13:09:48.533479 2277 imagestreamlookup.go:80] unscored >> rhdm73-kieserver-openshift: 1 >> I0916 13:09:48.533488 2277 imagestreamlookup.go:80] unscored >> rhdm73-optaweb-employee-rostering-openshift: 1 >> I0916 13:09:48.533497 2277 imagestreamlookup.go:80] unscored >> rhpam73-businesscentral-indexing-openshift: 1 >> I0916 13:09:48.533506 2277 imagestreamlookup.go:80] unscored >> rhpam73-businesscentral-monitoring-openshift: 1 >> I0916 13:09:48.533516 2277 imagestreamlookup.go:80] unscored >> rhpam73-businesscentral-openshift: 1 >> I0916 13:09:48.533525 2277 imagestreamlookup.go:80] unscored >> rhpam73-kieserver-openshift: 1 >> I0916 13:09:48.533534 2277 imagestreamlookup.go:80] unscored >> rhpam73-smartrouter-openshift: 1 >> I0916 13:09:48.533545 2277 imagestreamlookup.go:80] unscored ruby: 1 >> I0916 13:09:48.533553 2277 imagestreamlookup.go:80] unscored tests: 1 >> I0916 13:09:48.533596 2277 dockerimagelookup.go:87] checking remote >> registry for "jboss-eap72-openshift" >> I0916 13:09:48.819578 2277 dockerimagelookup.go:230] image import >> failed: v1.ImageImportStatus{Status:v1.Status{TypeMeta:v1.TypeMeta{Kind:"", >> APIVersion:""}, ListMeta:v1.ListMeta{SelfLink:"", ResourceVersion:"", >> Continue:""}, Status:"Failure", Message:"you may not have access to the >> Docker image \"jboss-eap72-openshift:latest\"", Reason:"Unauthorized", >> Details:(*v1.StatusDetails)(nil), Code:401}, Image:(*v1.Image)(nil), >> Tag:"latest"} >> F0916 13:09:48.819733 2277 helpers.go:114] error: unable to locate any >> images in image streams, local docker images with name >> "jboss-eap72-openshift" >> >> The 'oc new-app' command will match arguments to the following types: >> >> 1. Images tagged into image streams in the current project or the >> 'openshift' project >> - if you don't specify a tag, we'll add ':latest' >> 2. Images in the Docker Hub, on remote registries, or on the local >> Docker engine >> 3. Templates in the current project or the 'openshift' project >> 4. Git repository URLs or local paths that point to Git repositories >> >> --allow-missing-images can be used to point to an image that does not >> exist yet. >> >> See 'oc new-app -h' for examples. >> [zaphod@oc6010654212 ~]$ >> >> Regards, >> Marvin >> >> On Mon, Sep 16, 2019 at 12:59 PM Fernando Lozano <[email protected]> >> wrote: >> >>> Hi Marvin, >>> >>> It looks like there is something actually wrong with the standard image >>> streams. I have a "hello-word" app on my personal GitHub account. If fails >>> with the same error as you if I try to use the EAP image streams with the >>> "latest" tag implied: >>> >>> $ oc new-app jboss-eap72-openshift~ >>> https://github.com/flozanorht/war-hello --name war >>> error: unable to locate any images in image streams, local docker images >>> with name "jboss-eap72-openshift" >>> ... >>> >>> But if I use an explicit tag, such as 1.0, I it works just fine: >>> >>> $ oc get is jboss-eap72-openshift -n openshift >>> NAME IMAGE REPOSITORY >>> TAGS UPDATED >>> jboss-eap72-openshift >>> default-route-openshift-image-registry.apps-crc.testing/openshift/jboss-eap72-openshift >>> 1.0,latest 3 weeks ago >>> >>> $ oc new-app jboss-eap72-openshift:1.0~ >>> https://github.com/flozanorht/war-hello --name war >>> --> Found image 6189c3b (2 months old) in image stream >>> "openshift/jboss-eap72-openshift" under tag "1.0" for >>> "jboss-eap72-openshift:1.0" >>> ... >>> >>> It built my app successfully and I was able to access it, after exposing >>> a route. >>> >>> >>> []s, Fernando Lozano >>> >>> >>> >>> On Mon, Sep 16, 2019 at 1:48 PM Ben Parees <[email protected]> wrote: >>> >>>> Looks right to me, i'm not sure why new-app is not finding it. >>>> >>>> Can you try using the --image-stream openshift/jboss-eap72-openshift >>>> syntax instead of the ~ syntax and see if it makes a difference? >>>> >>>> also running with --loglevel=5 might give us more insight about why >>>> new-app is not finding your imagestream in the openshift namespace. >>>> >>>> >>>> On Mon, Sep 16, 2019 at 11:53 AM Just Marvin < >>>> [email protected]> wrote: >>>> >>>>> Ben, Fernando, >>>>> >>>>> From the output of "oc get is jboss-eap72-openshift -n openshift -o >>>>> yaml" >>>>> >>>>> status: >>>>> dockerImageRepository: >>>>> image-registry.openshift-image-registry.svc:5000/openshift/jboss-eap72-openshift >>>>> publicDockerImageRepository: >>>>> default-route-openshift-image-registry.apps-crc.testing/openshift/jboss-eap72-openshift >>>>> tags: >>>>> - items: >>>>> - created: "2019-08-23T17:59:24Z" >>>>> dockerImageReference: >>>>> registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7 >>>>> generation: 2 >>>>> image: >>>>> sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7 >>>>> tag: "1.0" >>>>> - items: >>>>> - created: "2019-08-23T17:59:24Z" >>>>> dockerImageReference: >>>>> registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:57dd3903b584970353a1b9503bc279a8082376e33dab7dc29825982ad9153235 >>>>> generation: 2 >>>>> image: >>>>> sha256:57dd3903b584970353a1b9503bc279a8082376e33dab7dc29825982ad9153235 >>>>> tag: latest >>>>> >>>>> Regards, >>>>> Marvin >>>>> >>>>> On Mon, Sep 16, 2019 at 11:20 AM Ben Parees <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Sep 16, 2019 at 11:04 AM Just Marvin < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Fernando, >>>>>>> >>>>>>> Thanks for the response, but that syntax is something that I >>>>>>> had tried before I posted, but it didn't work. >>>>>>> >>>>>>> [zaphod@oc6010654212 ~]$ oc new-app >>>>>>> jboss-eap72-openshift~git@github.....<github ssh url> >>>>>>> --name=humongous --source-secret=<CRC defined github secret> >>>>>>> error: unable to locate any images in image streams, local docker >>>>>>> images with name "jboss-eap72-openshift" >>>>>>> >>>>>>> The 'oc new-app' command will match arguments to the following types: >>>>>>> >>>>>>> 1. Images tagged into image streams in the current project or the >>>>>>> 'openshift' project >>>>>>> - if you don't specify a tag, we'll add ':latest' >>>>>>> 2. Images in the Docker Hub, on remote registries, or on the local >>>>>>> Docker engine >>>>>>> 3. Templates in the current project or the 'openshift' project >>>>>>> 4. Git repository URLs or local paths that point to Git >>>>>>> repositories >>>>>>> >>>>>>> --allow-missing-images can be used to point to an image that does >>>>>>> not exist yet. >>>>>>> >>>>>>> See 'oc new-app -h' for examples. >>>>>>> [zaphod@oc6010654212 ~]$ >>>>>>> >>>>>>> As I showed in my original email, the IS named >>>>>>> jboss-eap72-openshift, does exist. So, what am I doing wrong? >>>>>>> >>>>>> >>>>>> can you confirm the imagestream tags imported successfully? >>>>>> >>>>>> oc get is jboss-eap72-openshift -n openshift -o yaml >>>>>> >>>>>> if the imports succeeded, you should see something like this in the >>>>>> status section: >>>>>> >>>>>> status: >>>>>> dockerImageRepository: >>>>>> image-registry.openshift-image-registry.svc:5000/openshift/jboss-eap72-openshift >>>>>> tags: >>>>>> - items: >>>>>> - created: "2019-09-16T13:57:33Z" >>>>>> dockerImageReference: >>>>>> registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7 >>>>>> generation: 2 >>>>>> image: >>>>>> sha256:aef672575e93481d5a408e757562f6ed72b1736b5bc2ce92f3b2896e638db0c7 >>>>>> tag: "1.0" >>>>>> - items: >>>>>> - created: "2019-09-16T13:57:33Z" >>>>>> dockerImageReference: >>>>>> registry.redhat.io/jboss-eap-7/eap72-openshift@sha256:e78f3020712cf12dc04dfd325e5c4759c298cd1b805f4920a4f41995d469bb0d >>>>>> generation: 2 >>>>>> image: >>>>>> sha256:e78f3020712cf12dc04dfd325e5c4759c298cd1b805f4920a4f41995d469bb0d >>>>>> tag: latest >>>>>> >>>>>> >>>>>> >>>>>> if not, you should see an indication of why the import is not >>>>>> succeeding. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Marvin >>>>>>> >>>>>>> On Mon, Sep 16, 2019 at 9:59 AM Fernando Lozano <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> CRC comes ready to use, you do not need to perform any >>>>>>>> configuration to use an image stream from the 'openshift' namespace. >>>>>>>> That >>>>>>>> namespace already includes your pull secret (from your Red Hat >>>>>>>> Developers >>>>>>>> or customer portal account) that allows OpenSHift to pull container >>>>>>>> images >>>>>>>> from registry.redhat.io. >>>>>>>> >>>>>>>> The oc new-app command uses the 'openshift' namespace by default. >>>>>>>> You just need to use the image stream name (and tag if you wish) >>>>>>>> before a >>>>>>>> tilde (~) them provide your Git repository URL. >>>>>>>> >>>>>>>> See the following example, that uses one of the same application >>>>>>>> from the DO288 course. It uses the 'php' image stream from the >>>>>>>> 'openshift' >>>>>>>> namespace. >>>>>>>> >>>>>>>> $ oc new-app php:7.2~https://github.com/RedHatTraining/DO288-apps >>>>>>>> --name hello --context-dir php-helloworld >>>>>>>> >>>>>>>> []s, Fernando Lozano >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Sep 16, 2019 at 9:17 AM Just Marvin < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm working with code-ready-containers, and I can see that >>>>>>>>> there are image streams that I need in the openshift namespace (for >>>>>>>>> example, the jboss eap 7.2 image). The images themselves are not >>>>>>>>> local - >>>>>>>>> but on registry.redhat.io. My problem is two fold: (1) how do I >>>>>>>>> configure the cluster such that I can simply use these imagestreams >>>>>>>>> from a >>>>>>>>> new-app command (2) How do I set up the cluster so that any needed >>>>>>>>> authentication is pre-defined in the cluster. >>>>>>>>> >>>>>>>>> For (1): >>>>>>>>> >>>>>>>>> zaphod@oc6010654212 ~]$ oc describe is jboss-eap72-openshift -n >>>>>>>>> openshift >>>>>>>>> Name: jboss-eap72-openshift >>>>>>>>> Namespace: openshift >>>>>>>>> Created: 3 weeks ago >>>>>>>>> Labels: samples.operator.openshift.io/managed=true >>>>>>>>> Annotations: openshift.io/display-name=Red Hat JBoss EAP 7.2 >>>>>>>>> openshift.io/image.dockerRepositoryCheck=2019-08-23T17:59:24Z >>>>>>>>> openshift.io/provider-display-name=Red Hat, Inc. >>>>>>>>> samples.operator.openshift.io/version=4.1.11 >>>>>>>>> version=1.0 >>>>>>>>> Image Repository: >>>>>>>>> default-route-openshift-image-registry.apps-crc.testing/openshift/jboss-eap72-openshift >>>>>>>>> Image Lookup: local=false >>>>>>>>> Unique Images: 2 >>>>>>>>> Tags: 2 >>>>>>>>> >>>>>>>>> latest >>>>>>>>> tagged from >>>>>>>>> registry.redhat.io/jboss-eap-7/eap72-openshift:latest >>>>>>>>> prefer registry pullthrough when referencing this tag >>>>>>>>> >>>>>>>>> The problem here is that I can't work out the syntax of the >>>>>>>>> new-app command that can refer to an imagestream in a different >>>>>>>>> namespace >>>>>>>>> (openshift). How does one do this? >>>>>>>>> >>>>>>>>> For (2): >>>>>>>>> I think I need the equivalent of this page, to set things up: >>>>>>>>> https://docs.openshift.com/container-platform/3.11/install_config/configuring_red_hat_registry.html >>>>>>>>> . >>>>>>>>> However, I can't find the equivalent in the 4.1 docs. I suspect the >>>>>>>>> move to >>>>>>>>> a registry operator means that the procedure is completely different. >>>>>>>>> >>>>>>>>> In addition, I'm trying to use podman. I can login to >>>>>>>>> registry.redhat.io no problem, but I don't know where it stores >>>>>>>>> the token that I'll need to configure auth. Or atleast, I think thats >>>>>>>>> what >>>>>>>>> I need. Not sure.....do I actually have to but the userid + password >>>>>>>>> into >>>>>>>>> the cluster? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Marvin >>>>>>>>> _______________________________________________ >>>>>>>>> users mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> users mailing list >>>>>>> [email protected] >>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Ben Parees | OpenShift >>>>>> >>>>>> >>>> >>>> -- >>>> Ben Parees | OpenShift >>>> >>>> -- Ben Parees | OpenShift
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
