Add possibility to replicate version ranges?

[ikhandamirov]

Description:

The team has to decide, if we want to proactively add a possibility to replicate component version ranges, or if we rather wait and see, if there is customer demand for that feature. There was a discussion about this here and here.

Proposal:

• Wait for a customer request, and properly evaluate the request, if it comes.

Points to consider:

1. The purpose of the replication controller is to mimic the behavior of the ocm transfer cv command in a k8s environment. The the ocm transfer command, however, is not capable of transferring version ranges.
2. The primary use case for the replication controller is to facilitate delivery of new versions of bigger software products to a sovereign or air-gapped environment. An example of such a "big" product is Gardener. An attempt to transfer a large version range would result in a long-running process (days), network overload and increased potential for errors.
3. The replication controller should operate on a source Component resource, which has gone through successful reconciliation. If a certain version is exposed in the Component's status, it means that the version fulfills certain prerequisites, e.g. component version existence, accessibility, valid signature, etc. If the replication controller had chosen to operate on SemVer from Component's Spec, no assumptions about the quality of the Component could be made, which would increase probability for errors. To overcome this problem, if replication of version ranges is needed, the Component resource would have to expose a slice of verified component versions in its status, that would serve as the input for the Replication controller.
4. If working with version ranges, on each reconciliation the replication controller will have to decide on each component version from the range individually, if a transfer operation for that particular version has to be triggered.
5. If NOT working with version ranges, it can theoretically happen that some in-between component versions have not been replicated for some reason (e.g. target repository was not accessible), and the Component resource is meanwhile on a greater version. In such cases a manual workaround would be possible: either creation of a dedicated set of resources (Replication + Component) covering the missing version or a transfer with OCM CLI.

Done Criteria:

• The issue is discussed
• The outcome decision is documented
• Follow-up issues created, e.g. if decided to go on with proactive implementation