> On Nov 26, 2019, at 12:30 PM, Jon Stanley <jonstan...@gmail.com> wrote: > >> On Tue, Nov 26, 2019 at 10:29 AM Clayton Coleman <ccole...@redhat.com> wrote: >> The standard kube object >> is what we would normally output. You should be able to drop that in >> the manifests dir the installer creates to obviate the need for the >> content sources. > > Not sure that I follow here - should I use openshift-install create > manifests and then drop the kube object into the manifests dir (and > then presumably run openshift-install create ignition-configs) and > that obviates the need to add anything to install-config.yaml? I > thought that the use of create manifests was...discouraged :)
Excessively depending on the contents of the manifest dir is “bad”. Adding your own things there is not. > >> Also, in the future there will be other kube objects we output like a >> configmap containing the payload signature. > > OK, this is fine for me and my test clusters, but at $DAYJOB it's > going to get a bit more complicated to do that. We have a remote > registry setup to proxy out to quay.io, which we consider untrusted. > To get images into the internal registry, there's another process that > we already use for vendor images that we were hoping to leverage for > this (which includes a security scan). Requiring us to use the oc > tooling to get that configmap and any other future items would be > hard. There should be a way to output those objects without doing any > mirroring as such. That is what —dry-run will do in 4.3 > >> Do not hardcode! :) We plan to change locations in the future. > > You mean to something that doesn't say dev for production images? :) Where do you think baby production images come from? :) > _______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
