A stab

A control plane composite (the internal one) will be created with this. We can add more configs over time.

apiVersion: controlplane.spaces.upbound.io
kind: Instance
metadata:
  name: myctp
spec:
  forProvider:
    initialRestorationFrom:
      backupRef:
        name: myctp-backup-1
  writeConnectionSecretToRef:
    name: kubeconfig-dev
    namespace: upbound-system

A controller will reconcile this in given interval.

apiVersion: controlplane.spaces.upbound.io
kind: Sync
metadata:
  name: myctp-sync
spec:
  forProvider:
    targetConfigRef:
      type: Secret
      secretRef:
        name: kubeconfig-dev
        namespace: upbound-system
        key: kubeconfig
    source:
      repository:
        url: https://github.com/acmeorg/myctp-source
        ref: main
      interval: 10s

Backup is taken with the following, restore works by giving this to Instance.

apiVersion: controlplane.spaces.upbound.io
kind: Backup
metadata:
  name: myctp-backup-1
spec:
  forProvider:
    location:
      type: S3Bucket
      s3Bucket: {}

We can possibly have Role, RolePolicyAttachment as well in a Composition with the rest to be provisioned.

Observations

Except Instance, none of the others are actually managing external resources which is what MRs are meant for.
- Sync is a usual k8s controller - no external resource in another API to manage.
- Backup is also a usual k8s controller, saves a file to an S3 bucket. Since the controller itself produces that file, it does more than what an MR controller usually does.
Sync is weird to have as a separate resource since the git integration is meant to be a singleton, i.e. 1 source to 1 control plane. Having it as separate opens up the possibility of having more than one source to map to a control plane, which may be fine but not what we designed and it gets even closer to a shallow copy of FluxCD as well as introduces a constraint on the system, i.e. always think that there may be multiple syncs.

muvaf/controlplane.md

Observations