[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Machine parsing of 'oc adm release mirror'

> On Nov 26, 2019, at 12:30 PM, Jon Stanley <jonstanley gmail com> wrote:
>> On Tue, Nov 26, 2019 at 10:29 AM Clayton Coleman <ccoleman 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?  :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]