EPIC: Storage Migration from Flux Artifact Storage to OCI Registry

[morri-son]

Description
Since the openflux proposal failed, we have to adjust the architecture of the ocm-k8s-toolkit. In our conversation with the flux maintainers, they communicated that they might want to move towards oci registries as their storage backend instead of the current artifact store.

Based on that, the team proposed essentially 2 different approaches on how to adjust the architecture:

1. Replace all occurrences of the artifact storage with oci registry interactions and all occurrences of artifact crd with flux's oci repository crd. Therefore, the blobs (= content described by artifacts) have to be stored in oci registries as oci artifacts.
2. Replace all occurrences of the artifact storage with oci registry interactions BUT only use the blob storage API of the oci registry. In that case, we wouldn't replace all occurrences of the artifact crd with oci repository (as oci repository cannot address oci blobs). To connect that system to flux's Helm Release or Kustomization, we would still have to store the last blob (= content described by artifacts) as an oci artifact (= not just an oci blob) in an oci registry.
   ( Theoretically, there is a third hybrid approach, but that would of course have similar requirements )

We also already got feedback that if flux were to do this, they would go with the single layer oci artifact approach (1) - among other things, because the source controllers can already deal with that format.

---

The v1 ocm controllers already implemented a fully fledged pull through cache based on an oci registry as storage backend. For implementation details, check here:

Pull through Cache:
https://github.com/open-component-model/ocm-controller/blob/afc340ce2caf8c04f5c817bca07442a321b3631d/pkg/ocm/ocm.go#L172

Complete OCI Interaction including creating single layer oci images:
https://github.com/open-component-model/ocm-controller/tree/main/pkg/oci

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