One challenge is that you will need both segments, but only one of them is a standard kube object (the icsp). 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.
Also, in the future there will be other kube objects we output like a configmap containing the payload signature. We definitely need to make this easier to script though > On Nov 26, 2019, at 8:29 AM, Jon Stanley <jonstan...@gmail.com> wrote: > > At the end of an 'oc adm release mirror' instructions are printed as > to what imageContentSources I need to put in my install-config.yaml. > > Would it be a worthwhile enhancement to make an option such that what > I need to put in is ALL that is returned via stdout? This would make > it easier to, for example, automate the process of mirroring the > images (in particular, the nightlies which often change). That said, I > realize that regardless of the content that's mirrored, that block is > the same - but if at some future date, a new source gets added, for > example, that wouldn't be caught if I just hardcoded the > imageContentSources into my template install-config.yaml. Do not hardcode! :) We plan to change locations in the future. > > _______________________________________________ > users mailing list > users@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > _______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
