Uploaded image for project: 'OpenShift BuildConfig'
  1. OpenShift BuildConfig
  2. OCPBUILD-20

Build for allowing mirroring images by tags

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Won't Do
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • 2
    • False
    • False
    • Undefined

      User Story

      As a developer, I want OpenShift builds to use images mirroring by tags
      So that I do not have to use SHAs when building container images in a network restricted environment

      Acceptance Criteria

      • Docker strategy builds can reference an image by tag in a network restricted environment (for example, FROM image in a Dockerfile using a tag)
      • Source strategy builds can reference an image by tag in a network restricted environment (for example, referencing kind: DockerImage as the from image for a source strategy build).

      Docs Impact

      Builds do not reference mirroring in the docs today. The expectation is this will only require a release note.

      QE Impact

      QE will need to test this end to end manually on a network restricted cluster.
      Many of the Docker strategy tests in openshift/origin should test this capability on a restricted/disconnected cluster.

      PX Impact

      PX materials will be addressed by other stories in the parent epic. Once the mirror is set up and the cluster is configured appropriately, builds should just work.

      Notes

      A while back we created the openshift/runtime-utils repository to centralize the generation of cri-o configurations from the cluster ImageContentSourcePolicy.
      This configuration is passed to buildah in the build pod through a ConfigMap volume mount.
      The cri-o config generated in runtime-utils will need to be updated to handle the new configuration option for mirroring by tag. The containers engine team be the one doing this.
      The update would then be vendored into the build controller, which mounts the generated cri-o configuration into the build pod.
      The assumption is that this will just work...
      End to end testing in CI is likely not possible - when the PR is proposed we will need to rely on integration/unit tests.

      Uncertainty risk - does this capability also impact the internal registry? Will we run into unrelated issues for things like imagestream import?

      Open Questions

            Unassigned Unassigned
            qiwan233 Qi Wang
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: