Multiple XRs linking same Claim due to lack of resourceRef verification about crossplane HOT 5 OPEN

Why aren't ownerReferences used between the XR and the claim? This could allow for automatic deletion of the XR through garbage collection if the claim is removed. Is the intention behind this to facilitate the transfer of claims to different XRs within Crossplane? If so, how is crossplane designed to prevent a claim from being mistakenly associated from multiple XRs?

Because claims are namespaced and XRs are cluster-scoped and Kubernetes does not allow for ownerReferences between the two scopes. I think the Composite reconciler should check that the Claim it wants to point at is actually pointing back to it, and if not it should fail the reconciliation at that point.

from crossplane.

i wonder if fail is enough - when a claim is gone is it save to delete?

from crossplane.

Deletion of the claim should trigger deletion of the associated XR, so if the XR is pointing at a Claim that doesn't exist, it should probably be deleted. I wonder if using Foreground cascading deletion would mitigate the problem you are seeing, since the Claim controller will wait for the Composite to be completely deleted before returning back to the caller, which should guarantee no overlapping resources?

from crossplane.

If another component within the Helm release encounters an error (for example, a deployment fails to create pods, resulting in a crash loop), Flux attempts to roll back the release and can removing finalizers and deleting the resources including the Claim.

Are you saying that Flux is removing the finalizers Crossplane adds to the claim? This could cause the claim to be deleted before it's able to request that the XR it created be deleted.

from crossplane.

Why doesn't the XR check the resourceRef field in the claim to confirm if the claim is the correct one it's supposed to connect with? Another approach could be to include the UID from the XR in the claimRef to clearly identify which claim is associated with the XR.

The XR controller is actually unaware of claims. It's the claim controller that handles binding (setting the references). The claim controller checks, before binding:

• That the claim doesn't reference another XR.
• That the XR the claim references doesn't reference a different XR.

It doesn't check whether any other XR in the system already references the claim.

We don't consider a claim and XR fully bound unless they reference each other.

Deleting a claim will always delete the corresponding XR. You can't opt out of deleting the XR (you can only choose how to delete it - foreground or background). So the only way to end up with a leaked XR like this is if something interferes with the claim - i.e. deletes it and removes its finalizers before it has a chance to cleanup.

from crossplane.