Open nojnhuh opened 1 year ago
related to #1685
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
/kind api-change
What needs cleanup:
During reconciliation of virtual network resources, several fields under an AzureCluster's
spec.networkSpec.vnet
are backfilled with "actual" state gathered from the Azure API.These fields include:
id
tags
cidrBlocks
And under
spec.networkSpec.subnets
:cidrBlocks
Populating
spec
fields from a resource's own controller this way is considered an anti-pattern [citation needed, but IIRC mostly because of the not-entirely-philosophical "spec
= desired state,status
= actual state" distinction].Relevant code: https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/e7773fe017f3493be65c3368808d726a6343911e/azure/services/virtualnetworks/virtualnetworks.go#L91-L108
In addition to following Kubernetes best practices, part of the motivation for this change is to simplify the ASO implementation for reconciling vnets and remove a dependency on implementing ASO for subnets at the same time as for vnets.
Describe the solution you'd like
Instead of populating fields in
spec
representing "actual" state, the same info would fit better in an AzureCluster'sstatus
field. There, it would still be available from the API but not subject to the same validation which triggered the issue fixed by #2339 and would more clearly not collide with any user-specified values.Anything else you would like to add: This is to some degree a breaking change to the API, where users may currently be relying on the current behavior.