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 :) > 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. > Do not hardcode! :) We plan to change locations in the future. You mean to something that doesn't say dev for production images? :) _______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
