Currently oc adm release mirror has two knobs for wrapping release-image signature information into a ConfigMap and pushing that ConfigMap to different locations:

• --apply-release-image-signature to push it into a connected cluster.
• --release-image-signature-to-dir to push it into a file on removable media, which can be sneakernet'ed into the restricted-network environment and pushed into the cluster with oc apply ....

However, we currently lack a way to collect just the signature. For example, you might have:

1. Alice decides that 4.y.z should be a possible update target.
2. Alice uses oc adm release mirror ... to bring the images over to a local registry.
3. Bob creates a new 4.y.(z-1) cluster.
4. Bob decides to update their 4.y.(z-1) cluster to 4.y.z, but they need the local signature ConfigMap to verify the target release.
5. Bob takes steps to get the signature ConfigMap into their cluster.
6. Bob requests the update to 4.y.(z-1).
7. The CVO grabs the signature from the local ConfigMap, verifies the target, accepts the request, and begins updating.

In some future world, we may be able to store the release signature directly in the registry, in which case Alice can bring it over in step 2, and the cluster can pull it from the registry. But in the meantime, we still need the ConfigMap transfer in step 5. This ticket is about the UX for that step.

Possible options:

• adm release mirror --release-image-signature-to-dir=whatever --no-images $PULLSPEC or similar to ask for the signature ConfigMap without getting into the weight of the container-image content.
  • Trevor likes this.
  • mhrivnak@redhat.com is concerned that there is a format change from the bare signature to the ConfigMap-wrapped signature, and that "mirroring" suggests an absence of format changes. He's concerned about Bob thinking to look under oc adm release mirror ....
• Using oc adm release info --signature $PULLSPEC or similar to dump the bare signature to stdout, and piping that into oc create configmap ... to create the ConfigMap content. Because info is focused on viewing release content, and the ConfigMap wrapping would be explicitly applied by the caller.
  We were unable to work out an oc create configmap ... call in our old manual-ConfigMap-creation docs, but create configmap could be extended to close any gaps.
• Using oc adm release info --signature-config-map $PULLSPEC to dump the ConfigMap-wrapped signature to stdout.
  • Trevor is less excited about this, because info is aimed at viewing content, and packaging for shipping into clusters is getting further away from that core job.
• New word replacing mirror that allows for the possibility of format changes. adm release push --release-image-signature-to-dir=whatever --no-images $PULLSPEC or transfer or similar.
• Other?

Definition of done:

• Have a plan for the UX.
• Create next-step tickets (e.g. for implementing oc work, or filing enhancement proposals, or whatever).