-
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
🌱 Test and document controller ownerReferences #9153
🌱 Test and document controller ownerReferences #9153
Conversation
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.
IMO we should use this PR to close any gaps between what we see here and the intention expressed in #4014. I'll note them on the tables.
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.
One other note - the state of BlockOwnerDeletion
is not consistent across all of our types where Controller is true
I'd suggest setting this to true in all cases where controller is true.
|
||
## Owner reference relationships in Cluster API | ||
|
||
The below tables map out the a reference for ownership relationships for the objects in a Cluster API cluster. The tables are identical for classy and non-classy clusters. |
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.
classy and non-classy are the same as far as testing goes. I'm happy to have this as a principle to reduce complexity, but there's certain points where it may not make sense. e.g. for classy clusters KCP is created by the cluster controller, but for non-classy clusters it may be created by the user.
## KubeadmControlPlane types | ||
| type | Owner | Controller | Note | | ||
|-----------------------------|--------------|------------|------| | ||
| KubeadmControlPlane | Cluster | true | | |
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.
Should not be contolled by Cluster as the Cluster doesn't necessarily create it.
## Kubeadm bootstrap types | ||
| type | Owner | Controller | Note | | ||
|-----------------------|--------------|------------|-------------------------------------------------| | ||
| KubeadmConfig | Machine | true | When created for Machine | |
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.
This is created by the MachineSet controller and then the ownerReference is passed over. I think it's still fine to keep this as a controller though.
## Infrastructure provider types | ||
| type | Owner | Controller | Note | | ||
|-------------------------------|--------------|------------|---------------------------------------------| | ||
| InfrastructureMachine | Machine | yes | | |
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.
Similar to KubeadmConfig - this is passed over from the MachineSet / KCP controller.
| InfrastructureMachine | Machine | yes | | | ||
| InfrastructureMachineTemplate | Cluster | no | When created by cluster topology controller | | ||
| InfrastructureMachineTemplate | ClusterClass | no | When referenced in a ClusterClass | | ||
| InfrastructureCluster | Cluster | yes | | |
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.
Not true for classy clusters. Should probably be reverted to no.
| type | Owner | Controller | Note | | ||
|----------------------------|--------------------|------------|-------------------| | ||
| ClusterResourcesSet | None | | | | ||
| ClusterResourcesSetBinding | ClusterResourceSet | no | | |
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.
Should be yes.
| type | Owner | Controller | Note | | ||
|-----------------------|--------------|------------|-------------------------------------------------| | ||
| KubeadmConfig | Machine | true | When created for Machine | | ||
| KubeadmConfig | MachinePool | unknown | When created for MachinePool. Not tested in e2e | |
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.
We no longer test MachinePools in the quick start so this isn't covered. I can open an issue for this and tag folks that work regularly on MachinePools.
func hasExactOwnersByGVK(refList []metav1.OwnerReference, wantGVKs []schema.GroupVersionKind) error { | ||
refGVKs := []schema.GroupVersionKind{} | ||
// simpleOwnerRef is a simple representation of an ownerReference. | ||
type simpleOwnerRef struct { |
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.
A bunch of glue code changes to make the controller references comparable.
/test |
@killianmuldoon: The
The following commands are available to trigger optional jobs:
Use
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
7e70e12
to
0fd7f7c
Compare
/test pull-cluster-api-e2e-full-main |
/area api |
/hold I want to make sure the utils exposed here are right before merging. |
d3bb8dc
to
f4e80d7
Compare
/hold cancel I think we should get the initial state of this merged and I'll create an issue, or update the existing issue, with elements of our ownerShip graph that we may want to change based on this documentation and test. |
f4e80d7
to
4a89ffb
Compare
/test pull-cluster-api-e2e-full-main |
}, | ||
// ClusterResourcesSetBinding has ClusterResourceSet set as owners on creation. | ||
clusterResourceSetBindingKind: func(owners []metav1.OwnerReference) error { | ||
return hasExactOwnersByGVK(owners, []schema.GroupVersionKind{clusterResourceSetGVK}) | ||
return HasOneOfExactOwners(owners, []simpleOwnerRef{clusterResourceSetOwner}, []simpleOwnerRef{clusterResourceSetOwner, clusterResourceSetOwner}) |
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.
Mostly out of curiosity. Do you know why 1 or 2? Just the way our tests are written?
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.
ClusterResourceSetBinding will have as many owners as ClusterResourceSets it managed for a single cluster. I added the option of 2 here just to save me a rewrite in CAPV - can revert if you'd prefer.
I think this is one of the ownerReference that we should reconsider.
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.
Ah I see because doesn't matter how many CRS we have we will only have one ClusterResourceSetBinding per cluster, right?
(not really familiar with this stuff)
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.
Yeah - each Cluster will have one CRS binding, but each binding may represent multiple ClusterResourceSets
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.
WDYT about opening a follow-up issue to support something like ">=1 Owners of the same" in the assertion?
Definitely just a nice to have and we don't have to immediately follow-up. I think the current change is just a simple improvement to support more cases. So fine to merge as is
Signed-off-by: killianmuldoon <kmuldoon@vmware.com>
4a89ffb
to
cedb82e
Compare
/lgtm |
LGTM label has been added. Git tree hash: 387f9c8cc25f49e5cb4f8df4ca9c8867af0ce568
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbueringer 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 |
/cherry-pick release-1.5 |
@killianmuldoon: new pull request created: #9303 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Signed-off-by: killianmuldoon kmuldoon@vmware.com
Add tests and documentation for which ownerReferences should have
controller: true
for Cluster API objects.Part of #4014