You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the solution you'd like
Currently, ASO resource ownership is determined by the sigs.k8s.io_cluster-api-provider-azure_owned label whose value is the CAPI Cluster name. CAPZ does not modify or delete ASO resources without this label to allow users to manage their own ASO resources within a cluster.
A more Kubernetes-native mechanism to accomplish the same goal is to set an OwnerReference for the managing CAPZ resource, e.g. an ASO VirtualNetwork or VirtualNetworksSubnet would be owned by an AzureCluster or AzureManagedControlPlane and an ASO VirtualMachine would be owned by an AzureMachine. ASO already sets one OwnerReference to the parent ASO resource to inform the Kubernetes garbage collector. By adding another one for CAPZ with controller: true, we clarify that an ASO resource is not to be adopted by another controller.
In addition, tracking the resource hierarchy this way enables CAPZ to list all of the ASO resources of a particular kind managed by a CAPZ resource to enable reaping old resources (#4338). It would also make #4339 simple by way of the Owns() method on the controller builder. It also smooths the transition for other SDK-based services to ASO by no longer requiring each service Spec type to add a Namespace field for the ASO resource namespace since that can be derived from its CAPZ owner.
Anything else you would like to add:
Other considerations:
OwnerReferences cannot span namespaces. Would we ever want CAPZ to create ASO resources in a different namespace than its parent CAPZ resource?
Environment:
cluster-api-provider-azure version:
Kubernetes version: (use kubectl version):
OS (e.g. from /etc/os-release):
The text was updated successfully, but these errors were encountered:
/kind feature
Describe the solution you'd like
Currently, ASO resource ownership is determined by the
sigs.k8s.io_cluster-api-provider-azure_owned
label whose value is the CAPI Cluster name. CAPZ does not modify or delete ASO resources without this label to allow users to manage their own ASO resources within a cluster.A more Kubernetes-native mechanism to accomplish the same goal is to set an OwnerReference for the managing CAPZ resource, e.g. an ASO VirtualNetwork or VirtualNetworksSubnet would be owned by an AzureCluster or AzureManagedControlPlane and an ASO VirtualMachine would be owned by an AzureMachine. ASO already sets one OwnerReference to the parent ASO resource to inform the Kubernetes garbage collector. By adding another one for CAPZ with
controller: true
, we clarify that an ASO resource is not to be adopted by another controller.In addition, tracking the resource hierarchy this way enables CAPZ to list all of the ASO resources of a particular kind managed by a CAPZ resource to enable reaping old resources (#4338). It would also make #4339 simple by way of the
Owns()
method on the controller builder. It also smooths the transition for other SDK-based services to ASO by no longer requiring each serviceSpec
type to add aNamespace
field for the ASO resource namespace since that can be derived from its CAPZ owner.Anything else you would like to add:
Other considerations:
Environment:
kubectl version
):/etc/os-release
):The text was updated successfully, but these errors were encountered: