Implement Replication Controller

[fabianburth]

Description Implement a replication controller integrated into the ocm-k8s-toolkit that essentially maps the ocm transfer behaviour into a controller (exposing a subset of its options in the manifest). This allows transferring components into a private registry based on a "ocmops" based process.

I imagine the custom resource to look something like this:

apiVersion: delivery.ocm.software/v1alpha1
kind: Replication
metadata:
  name: replication
spec:
  componentRef:
     name: public-component
     namespace: default
  targetRepositoryRef:
     name: private-repository
     namespace: default
  interval: 10m0s
  suspend: false

As described in the following, there might be several more fields that might make sense to be added to the crd, this is essentially the absolute minimal version.

Here is the legacy implementation (I have not evaluated that yet).

The replication controller will have to consider the ocm config of the component custom resource specifying the component to be replicated. Note: This might be kind of ugly because currently, in ocm, there is no way to load only part of a ocm config. So there is no way to only load the resolver config but only the entire ocm config specified in that component.

The replication controller will not have to consider the ocm config of the repository custom resource specifying the target repository because while referenced components MAY BE fetched from multiple different repositories based on resolvers, referenced components MAY NOT BE transferred to multiple different repositories.

The replication controller will have to get uploader (aka. blob handler) configuration. Here, it has to be decided whether the replication custom resource has its own secretRef and configRef fields to specify ocm configuration or whether it takes the configuration of the target repository custom resource and we require to specify uploaders there. Or we might even do some kind of defaulting (so, if the replication custom resource has a config, use this, otherwise look for config in the target repository).

Or we might even implement the uploader configuration as a first class citizen in the api (so, provide dedicated fields on the replication custom resource). Generally, as part of this task, the transfer options of the ocm cli should be reviewed regarding whether it makes sense to offer some of them directly as part of the custom resource.

The verification controller itself will not do any kind of signature verification. The component descriptors will be verified by the component produced as result of a successful reconciliation of the replication custom resource. The resource will have to be verified after the download anyway, so by the resource controller or by other means (e.g. with the library or the cli).

The legacy implementation also offered signing the component version. This was primarily relevant in the context of MPAS, thus, we will omit this (at least for the start).

Done Criteria

• [ ] ...
• [ ] Code has been reviewed by other team members
• [ ] Internal technical Documentation created/updated
• [ ] New / changed code is documented
• [ ] Analysis of existing tests (Unit and Integration)
• [ ] Unit Tests created for new code or existing Unit Tests updated
• [ ] Integration Test Suite updated (includes deletion of existing unnecessary Integration Test and/or creation of new ones if required)
• [ ] Enduser Documentation updated (if applicable)
• [ ] Successful demonstration in Review

[ikhandamirov]

@morri-son, @fabianburth, is this a apart of a bigger scenario/story/epic? Would be good to know for me, what is depending on this task, and if there are any rough expectations for the availability date.

[ikhandamirov]

@fabianburth, maybe a silly question, but just to be sure. Is my understanding correct that this controller should be placed together with OCMRepository, Component und Resource ones (same repo)? And the same is also the case for Localization and Configuration? I.e. all the mentioned controllers are what the OCM K8s Toolkit consists of?

After re-reading the description more carefully:

replication controller integrated into the ocm-k8s-toolkit

putting it into the ocm-k8s-toolkit repo.

[morri-son]

@morri-son, @fabianburth, is this a apart of a bigger scenario/story/epic? Would be good to know for me, what is depending on this task, and if there are any rough expectations for the availability date. @ikhandamirov this is just one of a set of additional OCM controller. Therefore I now split the overall "OCM Remake" Epic into one Epic per controller, which can then be used to act as Epic for all tasks related to that specific controller. Ideally we're managing getting all new controllers playing together until beginning of November (meaning this will be the expectation of the delivery date 😉)