Changing Object.spec.forProvider.manifest.metadata.name orphans previous resource

[Avarei]

What happened?

After changing the Object.spec.forProvider.manifest.metadata.name the resource with the previous name does not get deleted.

How can we reproduce it?

Create a Resource:

apiVersion: kubernetes.crossplane.io/v1alpha2
kind: Object
metadata:
  name: foo
spec:
  forProvider:
    manifest:
      apiVersion: v1
      kind: ConfigMap
      metadata:
        namespace: default
        name: test1

Change the Resource

apiVersion: kubernetes.crossplane.io/v1alpha2
kind: Object
metadata:
  name: foo
spec:
  forProvider:
    manifest:
      apiVersion: v1
      kind: ConfigMap
      metadata:
        namespace: default
        name: test2

run kubectl get cm -n default and observe both test1 and test2 are present.

What environment did it happen in?

Provider Kubernetes: v0.14.1
Crossplane version: v1.16.0
Kubernetes: v1.28.8

[bobh66]

I believe this is the expected behavior, at least for the current implementation. metadata.name is a "special" field since it defines the "key" to the object and the operator does not expect the key to change. That would require deleting the old Object and creating a new one with a new name.

[LCaparelli]

It seems Crossplane itself deals with a similar problem for composed resources, controlling them via spec.resourceRefs. Current behavior there ensures that resources that are no longer part of the desired state get deleted.

Would it make sense for a similar control to be implemented here?

Chiming in with a use-case: we want to control Jobs, whose pod template is (unfortunately) immutable. We thought of working around this by ensuring the resource name changes when we change something we'd like to trigger a new Job for.

I believe the same can be said for anything that's immutable, and we're ok with creating a new one.