Feature Overview (aka. Goal Summary)  

An elevator pitch (value statement) that describes the Feature in a clear, concise way.  Complete during New status.

 ----- copied from RFE-4798 -----
1. Proposed title of this feature request

• oc-mirror configuration of target repo/tag in the mirroring of additionalImages 
• Option to configure target repo/tag 

2. What is the nature and description of the request?
When doing image mirroring using the `oc` client tool, we have full control of what the namespace/repo/tag of the image will be in the target registry. Like in following example where image `[docker.io/library/busybox:latest]` (http://docker.io/library/busybox:latest) is mirrored to target registry as `${MIRROR_REGISTRY}/jukosone/test1/foo/bar/busy:test`

• Mirror from source registry to local file system:

  $ oc image mirror \
   -a /root/configs/pull-secret.json \
   docker.io/library/busybox:latest \
   file://test1/busybox:latest

• Mirror from local file system to target registry:

  $ oc image mirror \
   -a /root/configs/pull-secret.json \
   file://test1/busybox:latest \
   ${MIRROR_REGISTRY}/jukosone/test1/foo/bar/busy:test
  

   

Similar cannot be achieved when using `oc-mirror` based mirroring; there is no option for a user to define a repository/tag, but those are permanently fixed to the same as in the source. 
For example:

$ cat imagesetconfig.yaml
apiVersion: [mirror.openshift.io/v1alpha2](http://mirror.openshift.io/v1alpha2)
kind: ImageSetConfiguration
mirror:
  additionalImages:
name: [docker.io/library/busybox:latest](http://docker.io/library/busybox:latest)

• Mirror from source registry to local filesystem:

  $ oc-mirror \
   --config imagesetconfig.yaml \
   file://archive

• Mirror from local filesystem to target registry:

  $ oc-mirror \
    --from archive/ \
    docker://${MIRROR_REGISTRY}/jukosone/test2/foo/bar

   

Results to:

$ cat imageContentSourcePolicy.yaml
apiVersion: [operator.openshift.io/v1alpha1](http://operator.openshift.io/v1alpha1)
kind: ImageContentSourcePolicy
metadata:
  name: generic-0
spec:
  repositoryDigestMirrors:
* mirrors:
    * ocp-team-local.artifactory-example.com:443/jukosone/test2/foo/bar/library
    source: [docker.io/library](http://docker.io/library)

$ cat mapping.txt
[docker.io/library/busybox@sha256:3fbc632167424a6d997e74f52b878d7cc478225cffac6bc977eedfe51c7f4e79=ocp-team-local.artifactory-example.com:443/jukosone/test2/foo/bar/library/busybox:latest](http://docker.io/library/busybox@sha256:3fbc632167424a6d997e74f52b878d7cc478225cffac6bc977eedfe51c7f4e79=ocp-team-local.artifactory-example.com:443/jukosone/test2/foo/bar/library/busybox:latest)

Where repo/tag is library/busybox:latest and user cannot affect the naming here.
Add a feature to oc-mirror that enables a user to configure image namespace/repo/tag?

We can use mirror.operators.targetCatalog and mirror.operators.targetTag. But it is only for operators so we want to be able to export this option to all areas like additionalImages for example.

3. Why does the customer need this?

• It is not practical to use oc-mirror in additional image mirroring due to lack of reconfigurability.

4. List any affected packages or components.

• oc-mirror
   ------------------------------------------------------

<your text here>

Goals (aka. expected user outcomes)

The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

<your text here>

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete.  Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc.  Initial completion during Refinement status.

 This Feature was generated in OCPSTRAT via acceptance of RFE-4798. Ensure the stated Acceptance Criteria below will fulfill the needs specified in the RFE.

<enter general Feature acceptance here>

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

<your text here>

Questions to Answer (Optional):

Include a list of refinement / architectural questions that may need to be answered before coding can begin.  Initial completion during Refinement status.

<your text here>

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

<your text here>

Background

Provide any additional context is needed to frame the feature.  Initial completion during Refinement status.

<your text here>

Customer Considerations

Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.

<your text here>

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

<your text here>

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>