✨ Add Upsync controller

[bipuladh]

Signed-off-by: Bipul Adhikari badhikar@redhat.com

Summary

Adds Upsync controller
Creates resources in the Upstream workspace for labelled resources.

[davidfestal]

@bipuladh if a PR was not yet in a reviewable state (which was the case of this PR in its initlal state if I understood correctly what you told me), then you can also created it as a DRAFT PR, which makes it even clearer for other team members.

[sttts]

downstreamObject would match upstreamObject

[davidfestal]

wdym ?

[mamachanko]

question: What are the upsyncable resource types?

[mamachanko]

I think upsyncable resources are limited to pods, endpoints and persistentvolumeclaims. Both experimentation and code support my understanding:

/~https://github.com/bipuladh/kcp/blob/6cf3293ff35c3558e032c0cd3e4a00724c00e9ec/pkg/syncer/syncer.go#L236-L245

[davidfestal]

That's right, for now only these 3 resources are upsynced, since they correspond to the use-cases forseeable short-term.
Mid-term / long-term, we should have followup work that would allow customizing this list at the KCP level (and possibly storing it to the Synctarget status), but this still needs further design and discussion, especially to keep security in mind.

We should probably open a dedicated issue for this, to track the first thoughts we had in the regard, and further discuss the details.

[sttts]

The upsync controller is agnostic which GVRs are upsynced. But we are very opinionated in the wiring into the syncer for the moment. Whether we open that up eventually in some way, we will see.

[mamachanko]

Thanks @davidfestal @sttts

We should probably open a dedicated issue for this, to track the first thoughts we had in the regard, and further discuss the details.

I can take care of that.

[pdettori]

Any thoughts on how we could address Crossplane use cases ? (this is a similar use case to the one demoed by @sttts at Kubecon NA 2022 for Kube-bind). In this use case, Crossplane is installed in the physical cluster and Crossplane claims CRDs are imported in the kcp workspace. Crossplane claims typically create connection secrets, which are created in the backend cluster. But to give access to the resources created by those claims, the developer need to have access to the connection secret. Therefore, the connection secret should be up synced to the workspace where the claim lives. I created a PoC for a controller that runs downstream and for each Crossplane connection secret finds the owner (the down-synced claim) and can add the UpsSync label to the connection secret. I was hoping to use this PR to now close the loop and be able to up sync the connection secret. But it looks like with the current restriction that will not be possible unless I create my own fork for the syncer.

[davidfestal]

I created the related issue here: /~https://github.com/kcp-dev/kcp/issues/2804

Let's discuss in this new issue.

[pdettori]

Thanks ! I will copy the Crossplane use case description there.

[mamachanko]

Thanks for creating the issue @davidfestal you were faster than me 🙇🏻

[sttts]

/lgtm
/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sttts

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/syncer/OWNERS [sttts]
• test/OWNERS [sttts]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment