Restart XR and claim controllers when XRDs are updated

[muvaf]

What problem are you facing?

I might be the only one who knows about this since I did the initial implementation so we need to document it. The reason is that we spin up a new controller for every CRD we produce but those controllers work on the cached schema, so the schema cache needs to be refreshed and that doesn't happen unless you restart the pod (the last I checked).

How could Crossplane help solve your problem?

Add this to composition reference doc.

[jbw976]

@muvaf is there not a programmatic way to invalidate the cache, or perform a new discovery or something? If folks have to manually restart the crossplane pod when making an update to a XRD then lots of people are going to get bit by then, even if it is documented 😇

[negz]

I believe deleting and recreating the XRD will work too.

I could imagine it's possible for us to notice when the XRD has changed and restart the controller. For example we could update controller.Start to take a "configuration id" argument as well as the unique name of the controller. Today if you try to start a controller that is already started it's a no-op. We could update that such that starting a controller with the same configuration would be a no-op, but starting a controller with a new configuration would cause it to be restarted. We could just use a hash of the XRD spec as the configuration id.

https://github.com/crossplane/crossplane/blob/423fc6/internal/controller/apiextensions/definition/reconciler.go#L458
https://github.com/crossplane/crossplane-runtime/blob/65044f0/pkg/controller/engine.go#L167

[plumbis]

Fixed in #475