Take API server out of XR name generation path

[pedjak]

What problem are you facing?

After a claim is deployed to the cluster, its counterpart composite needs to be created. Its name is derived from the claim's name, by adding a suffix. The final name is obtained sending a dry-run create request to API server.

The Kubernetes docs is strongly suggesting not to rely on such generated values - the name could be taken at the moment when the real request is submitted.

How could Crossplane help solve your problem?

Claim controller can generate the composite name without contacting API server, and hence speeding up the reconciliation. Claim's UID poses enough entropy, and it would be enough to take some part of it (last N chars, e.g. N > 6) and append it to the original claim name.

[negz]

We use a similar pattern to name an XR's composed resources. We could probably extend what is proposed here, i.e.:

• Derive XR name suffix from Claim UID.
• Derive composed resource names from XR UID.

[sttts]

Why is dry-run needed in the first place? Why not just go ahead and create the XR and let the apiserver do its work of finding a name?

[turkenh]

Take API server out of XR name generation path

Apparently, it is not possible to achieve this. For any randomly generated name, we need to double check with the API server that it is not taken during generation. Also the name we ensured that is available (either via "dry-run" or "try get and see not found") could be taken until we do the actual Create. And even worse, if we don't do a Create but Update or Patch (e.g. Server Side Apply) we might be overriding a composite that is owned by another claim.

We already replaced "dry-run" with a "try get and see not found" approach in #5062 for claim -> composite and #4858 for composite -> composed which gives us consistent generated names to fix issues like this. However, the other problem of possibly overriding other composites & composed resources still exist and being tracked with:

• A new claim could update an existing composite #5104
• A composition can update existing managed resource #5122

Hence, I am closing this issue in favor of the above issues which better describe the actual problem.