Story (Required)

As a pipelines service developer trying to deploy OSP nightly build in RHTAP, I'm facing an issue while trying to apply the ImageContentSourcePolicy included in the build.

-> oc apply -f image-content-source-policy.yaml 
Error from server (Managed OpenShift customers may not create ImageContentSourcePolicy, ImageDigestMirrorSet, or ImageTagMirrorSet resources that configure mirrors that would conflict with system registries (e.g. quay.io, registry.redhat.io, registry.access.redhat.com, etc). For more details, see https://docs.openshift.com/): error when creating "image-content-source-policy.yaml": admission webhook "imagecontentpolicies-validation.managed.openshift.io" denied the request: Managed OpenShift customers may not create ImageContentSourcePolicy, ImageDigestMirrorSet, or ImageTagMirrorSet resources that configure mirrors that would conflict with system registries (e.g. quay.io, registry.redhat.io, registry.access.redhat.com, etc). For more details, see https://docs.openshift.com/

Now there is https://access.redhat.com/solutions/6967643 which states the issue is resolved and was able to track down the issue to specific image

  - mirrors:                                                                 - quay.io/openshift-pipeline/ubi8-openjdk-11                             source: registry.access.redhat.com/ubi8/openjdk-11 

When that image is removed from the list, the manifest applies without further issues.

Background (Required)

The OSP nightly builds are ultimately deployed on AWS cluster, but before getting there they are tested in 2 CI systems, the Pipeline Service CI and the RHTAP CI and both use ROSA clusters to deploy OSP and run a set of tests. With the provided image-content-source-policy.yaml failing to apply to a ROSA cluster, we can't go any further and deploy OSP.

The ImageContentSourcePolicy manifests applies on a AWS OCP cluster, but not on a ROSA one as used in CI.

Out of scope

<Defines what is not included in this story>

Approach (Required)

<Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

Dependencies

<Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

Acceptance Criteria (Mandatory)

<Describe edge cases to consider when implementing the story and defining tests>

<Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

INVEST Checklist

Dependencies identified

Blockers noted and expected delivery timelines set

Design is implementable

Acceptance criteria agreed upon

Story estimated

Legend

Unknown

Verified

Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met