Ensure owner references are correctly re-reconciled

[killianmuldoon]

The test in ##7569 shows that some of the ownerReferences in Cluster API are not correctly re-reconciled if they are removed for any reason. This is an umbrella issue to capture the different cases under which this can happen.

The expectation is that the ownerReference tree should look the same as on cluster creation after being re-reconciled. The following differences can be seen in #7569

1. KCP machines and standalone MachineSets can be wrongly adopted by the Cluster on re-reconcile
   • 🐛 Fix Machine adoption for KCP/MachineSet-owned Machines #7591
2. Secret ownerReferences are not re-rereconciled correctly Secret ownerReferences not restored #6979
   • 🐛 Fix kubeadmconfig bootstrapsecret ownerRef reconciliation #7587
   • additional bug fix in 🐛 Fix bug in kubeadmconfig adoption #7623
   • 🐛 Fix adoption KubeadmControlPlane owned secrets  #7592
3. ClusterResourceSet configmap references are not re-reconciled
   • 🐛 Fix adopting ClusterResourceSet resource by CRS when already applied #7590
4. KubeadmConfig and DockerMachines created by a MachineSet are initially created with two OwnerReferences: 1 for the Machine it's linked to and a second for the higher level controlling type or MachineSet.
   • 🌱 Ensure infra and bootstrap objects are owned by Machines #7593
5. ClusterClass-owned templates are not re-reconciled with their ownerReferences (There is an issue here where the ClusterClass is reconciled infrequently so it takes longer for these references to be re-reconciled. The ownerReference tree is evenually as expected in this case though, as the ClusterClass controller reconciles these references correctly.)

ClusterClass clusters

The ownerReference tree on creation:

The ownerReference tree after removing and re-reconciling:

Non-ClusterClass clusters

The ownerReference tree on

creation:

The ownerReference tree after removing and re-reconciling

/kind bug

[sbueringer]

/triage accepted

@killianmuldoon I'm not sure who is already working on which sub-task. Please let me know if I should take over one of them.

[killianmuldoon]

/assign

[fabriziopandini]

Thanks for this extensive work of research.
Most of the issues are due to support for some "legacy" stuff, like control-plane machines without a control-plane object controlling them, or stand-alone machines. I will trigger some discussion about dropping support for some of this, which is healthy for the entire project.

But, for now, praise for this work making the project more robust and resilient to ownerRefs being accidentally removed.

[sbueringer]

I will trigger some discussion about triggering the process for dropping support for some of this, which is healthy for the entire project.

Thx. Absolutely agree. We should continuously try to get rid of things which are not needed anymore.

But, for now, praise for this work making the project more robust and resilient to ownerRefs being accidentally removed.

+100. Thx @killianmuldoon great work!!

[sbueringer]

Looks like #7587 introduced a bug: https://github.com/kubernetes-sigs/cluster-api/pull/7616/files#r1031946701

[sbueringer]

@killianmuldoon Just out of curiosity in case you just know it.

Is the ClusterClass ownerRef tree equivalent to the non-ClusterClass tree just with more ownerRefs for the ClusterClass+referenced templates? (it's a bit hard to diff in the pictures)

[killianmuldoon]

All tasks now done - will close this once #7606 is merged.

[killianmuldoon]

/close

#7606 is approved