-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🌱 Add ownerRefs to BootstrapConfig/InfraMachinePool in classy Clusters #9389
🌱 Add ownerRefs to BootstrapConfig/InfraMachinePool in classy Clusters #9389
Conversation
Signed-off-by: Stefan Büringer buringerst@vmware.com
/assign @killianmuldoon |
/test pull-cluster-api-e2e-full-main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely makes sense to me.
/lgtm
LGTM label has been added. Git tree hash: 7e422934c38d9ee08deffa5c3534edbcbaf65136
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/area clusterclass
/assign @chrischdi @killianmuldoon Would it be fine to merge after Christian reviewed it as well? Or do you think we should get Fabrizio's review? |
I'm not fully read into the context here - was there some decision made about this in some of the other MachinePool ClusterClass PRs? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
One nice addition - I see it's already a follow-up on #5991 would be to add ownerRef validation for MachinePools in e2e. |
I intentionally didn't include it in the first PR because I wanted to think about it some more. Apart from that nobody has any MP-specific context :) I'm basically reversing the temporary decision to diverge from MachineDeployments. I think this could basically work the same way for MPs as for MDs. We add the Cluster as an ownerRef which means worst case the objects are getting cleaned up when the Cluster gets cleaned up. Usually they are explicitly deleted by the MP controller during reconcileDelete. It's not perfect, but feels as good/bad as what we have for MDs Regular cleanup for templates referenced in MDs is a lot more complicated, but I think the fallback cleanup case is here the same for MP/MD. |
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: killianmuldoon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Stefan Büringer buringerst@vmware.com
What this PR does / why we need it:
Thought about this for a bit. I think it makes sense to do the same as in the MD case.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Part of #5991