Integrate provider-jet-cloudscale for Backups

[ccremer]

Summary

As cluster-admin\ I want automatic provisioning of S3 buckets and users\ So that I can finish the Backup and Restore feature for instances.

Context

Integrate https://github.com/vshn/provider-jet-cloudscale into the stack so we can provision S3 buckets for the instance backups.

Out of Scope

• Provisioning buckets via some cloud API

Further links

No response

Acceptance Criteria

Given an instance with Backups enabled
When Operator reconciles the instance CR
Then an S3 bucket from cloudscale.ch is usable and ready for K8up backups

Implementation Ideas

Idea:

• The operator would deploy a Kubernetes resource that automatically provisions S3 buckets and users.
• Howver, instead of deploying resources for provider-jet-cloudscale via code, we deploy a claim of a Crossplane composition
• That composition is maintained by the cluster administrator (or more precise: in the Commodore component)
• The implementation of the composition is cloud-specific: For cloudscale.ch, the provider-jet-clouscale resources are in this composition.
• For local development, we engineer a composition that deploys buckets with Minio. See existing example in the prototype: https://github.com/vshn/appcat-service-prototype/blob/master/minio/s3-composition.yaml
• To deploy resources without Go API (structs), we can use Unstructured from the kubernetes unstructured package (https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured).

This makes it possible so that the Operator can request provisioning of S3 buckets for any infrastructure and we don't need to switch-case within code. However, this also makes it more complex...

Alternatively, we can try to just provision the provider-jet-cloudscale resources directly in the code, even if that makes local development of backups with buckets harder (since one would need a cloudscale.ch account with billing set up and some test buckets).

[zugao]

I see crossplane being mentioned in this issue. We need first to discuss the if we still want to keep it

[ccremer]

I see crossplane being mentioned in this issue. We need first to discuss the if we still want to keep it

The issue with maybe getting rid of provider-helm is completely independent discussion of this issue here.

This issue here is about engineering support for different S3 providers (minio, cloudscale etc).

If we don't use want to use crossplane here, then we can either:

• only support provider-jet-cloudscale for the time being, meaning we can't test backups locally with minio. For local testing, we'll need cloudscale buckets and accounts.
• support multiple S3 providers via code from the beginning. This means we need to add fields in the OperatorConfig CRD where we can define and configure which provider to use, and in code we have to switch between different provider implementations based on those config (e.g. provider-jet-cloudscale if on cloudscale, using minio API if using locally, or engineer provider-jet-minio and, later on, provider-jet-exoscale). So we'll have to engineer a switch in the code somehow.

With Crossplane we'd essentially engineer the switch at the cluster-level, not in code. For example, to provision buckets with minio, the composition is engineered so that buckets with minio are provisioned when creating claims. To support cloudscale, in the component we "implement" the composition so it uses provider-jet-cloudscale. This is transparent for the operator, the operator doesn't know or care which S3 provider is used. This merely moves the feature to support different kinds of S3 providers outside of the code, but we need this kind of switch at some point somewhere. Complexity isn't that much reduced here, just moved to a different kind of implementation.

[ccremer]

As discussed internally, this is now replaced with #78