Remove backfilling to AzureCluster spec from vnet reconciliation

[nojnhuh]

/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:

cluster-api-provider-azure/azure/services/virtualnetworks/virtualnetworks.go

Lines 91 to 108 in e7773fe

	vnet := s.Scope.Vnet()
	vnet.ID = ptr.Deref(existingVnet.ID, "")
	vnet.Tags = converters.MapToTags(existingVnet.Tags)
	var prefixes []string
	if existingVnet.VirtualNetworkPropertiesFormat != nil && existingVnet.VirtualNetworkPropertiesFormat.AddressSpace != nil {
	prefixes = azure.StringSlice(existingVnet.VirtualNetworkPropertiesFormat.AddressSpace.AddressPrefixes)
	}
	vnet.CIDRBlocks = prefixes
	// Update the subnet CIDRs if they already exist.
	// This makes sure the subnet CIDRs are up to date and there are no validation errors when updating the VNet.
	// Subnets that are not part of this cluster spec are silently ignored.
	if existingVnet.Subnets != nil {
	for _, subnet := range *existingVnet.Subnets {
	s.Scope.UpdateSubnetCIDRs(ptr.Deref(subnet.Name, ""), converters.GetSubnetAddresses(subnet))
	}
	}

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's status 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.

[CecileRobertMichon]

related to #1685

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[nojnhuh]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[nawazkh]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[nawazkh]

/remove-lifecycle stale