feature: mutate spec object references for other published resources

[embik]

Feature Description

For namespaced resources, syncing from kcp to a Kubernetes cluster (3D space to 2D space, in a way) is usually not a problem because our default resource renaming rules put everything under its own namespace, so e.g. related resources such as Secrets do not create problems with their naming (a secretRef in an object pointing to my-secret is not creating conflicts because everything will happen in a generated namespace of the format WORKSPACE-NAMESPACE [with hashes, but you get the idea]).

This is however not possible with cluster-scoped resources in general, plus referencing other published resources would also create similar problems. Think of the following manifests that I want to create in kcp with both being synced down to a service provider cluster:

apiVersion: service/v1
kind: Config # a cluster-scoped resource
metadata:
  name: my-config
spec: {}
---
apiVersion: service/v1
kind: ServiceInstance # a namespace-scoped resource
metadata:
  name: my-instance
  namespace: my-namespace
spec:
  configRef:
    name: my-config # a reference to my Config object from above

What is needed is a way to describe object references like this (basically say: spec.configRef.name in the ServiceInstance kind is a reference to another resource that is within the realm of the api-syncagent) in PublishedResources.

Since the api-syncagent knows about the renaming rules of other resources published via PublishedResources, it should mutate spec.configRef.name to the name that it translated the my-config object to. So on the service provider side, these objects should look somewhat like this:

apiVersion: service/v1
kind: Config # a cluster-scoped resource
metadata:
  name: iuc6yffea77crveb-7505d64a54e061b7acd5
spec: {}
---
apiVersion: service/v1
kind: ServiceInstance # a namespace-scoped resource
metadata:
  name: my-instance
  namespace: org-ucdyfdsa7trvfa-sdadsjdjwwewads
spec:
  configRef:
    name: iuc6yffea77crveb-7505d64a54e061b7acd5 # a reference to my Config object from above

Proposed Solution

I'm not fully clear on how the API should look, but most likely a PublishedResource should have a way to mark object references and define what resource is being referenced here. The api-syncagent would need to hold an internal representation of all renaming rules depending on resources, and would then use those rules in the mutation phase we recently re-enabled in #19.

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

No response