Uploaded image for project: 'OpenShift Over the Air'
  1. OpenShift Over the Air
  2. OTA-667

UX for mirror ImageContentSourcePolicy access

XMLWordPrintable

    • Icon: Spike Spike
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • None
    • 3
    • False
    • None
    • False
    • OTA 224, OTA 225

      Currently oc adm release mirror ... writes imageContentSources (for the install-config) and ImageContentSourcePolicy (for post-install cluster updates) to stdout. But copy/pasting that content out of the command output is tedious to automate, with folks resorting to hacks like grep. Ideally there would be a way to get that content spit out into files on disk, so consuming scripts could do something less brittle.

      One option would be to follow oc adm catalog mirror ..., where --to-manifests writes the ImageContentSourcePolicy to imagecontentsourcepolicy.yaml. This has the benefit of pattern-matching an existing option. But there are some drawbacks:

      • I dunno if we have a clear definition of "manifests", but it's not obvious that the imageContentSources install-config snippet qualifies.
      • I prefer options that talk about what is going where, and --to-manifests is leaving both of those implicit, and only talking about the format of the content.
      • Back when we were talking about release image mirroring, I'd initially pitched --config-to-dir and --apply-config for moving "all the non-image config stuff" to disk or a connected cluster respectively. But Clayton was not conviced, and preferred explicit names for each touched type.

      So maybe --image-content-sources-to-dir, --image-content-source-policy-to-dir, and --apply-image-content-source-policy? And we may also want to tie that in with OTA-666, because after Alice has already mirrored images, when Bob goes to create his new cluster, he will still want the imageContentSources blurb, but probably does not want to download or ship around gigs of image layer data.

      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).

              jottofar Jack Ottofaro (Inactive)
              trking W. Trevor King
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: