Bug: Misalignment between CRD spec and its status

[antonioquintavalle1A]

Describe the bug

PrivateDnsZonesARecord has the following definition:

.spec.AzureName

https://github.com/Azure/azure-service-operator/blob/main/v2/api/network/v1api20240601/private_dns_zones_a_record_types_gen.go#L386

but its status reports:

https://github.com/Azure/azure-service-operator/blob/main/v2/api/network/v1api20240601/private_dns_zones_a_record_types_gen.go#L1282

Expected behavior

.spec and .status should have consistent naming

To Reproduce

create a CR having: apiVersion: network.azure.com/v1api20200601
kind: PrivateDnsZonesARecord
`

Additional context

Here's a scenario why we shall take care of this:
1 - A privateDnsZonesARecord already exists in Azure
2 - We create a CR locally on the k8s cluster, with serviceoperator.azure.com/reconcile-policy: skip, providing only .spec.owner.armid and .spec.azureName
3 - K8S will leave an empty .spec (as expected) and will reflect the current status of the resource in its .status field.
4 - We want to align content of .spec to .status so that we can let ASO control the remote resource from now onwards, changing the annotation to serviceoperator.azure.com/reconcile-policy: manage.

Having a consistent naming convention between .spec and .status would allow us to convert this pretty easily by reading the CR payload and ingesting this into jq/yq by removing the old .spec key and renaming .status into .spec.

Without parsing and post-processing is required and this could be tedious and subjected to future changes.

Do you think this might be considered a valuable use case for other scenarios?

[theunrepentantgeek]

We were forced into this situation because the constraints on name differ between Kubernetes and Azure in incompatible ways.

In Kubernetes, name must be DNS compliant (limiting the available character set) and unique in the namespace.

In Azure, the set of characters allowable for name differs from resource to resource (e.g. ACR does not allow hyphens -), and some resources have strict requirements (e.g. RoleAssignments must be GUIDs) or fixed names (e.g. a RedisCacheSpec must always be called default).

We found very early on in this project that there was a compelling case that the name of the Kubernetes Resource needed to be able to vary from the azureName of that resource in Azure.

To change the name of the property on .spec would be a breaking change impacting all current users.

[theunrepentantgeek]

Notwithstanding the above, importing an existing Azure resource is a scenario we've already addressed.

Our command line tool, asoctl, allows you to import a resource from Azure, emitting a yaml file with the resource presented in ASO format.

This functionality can be used three different ways. In order of how much control they give you over the end result, they are:

• By running asoctl import azure-resource on the command line. [docs]
• By importing the asoctl functionality in your own runner (see the importresources library)
• By importing the relevant api package and using the ImportableResource interface

[theunrepentantgeek]

Another approach would be to extend the serviceoperator.azure.com/reconcile-policy annotation with a new option, say import, which would result in a blank spec being overwritten by the first observed status of the resource, locking the state of the resource in place. This has close links with #2703.

There are obvious limitations with this approach - ASO is unable to infer configuration for configmaps or secrets, for example, but this may still be useful.

[antonioquintavalle1A]

Would you have any return on experience from other users of ASO about what might be a suitable generic approach?

I'd tend to say asoctl adds up a bit of overhead to have the manifest correctly generated but it still requires an external action (e.g. in case a fleet of cluster must have the same manifest, we need to call asoctl and generate its content, commit and push change, have it deployed everywhere is needed).

[theunrepentantgeek]

We exposed the import functionality from asoctl as a library in response to a user request, as they wanted to automate adoption of resources in their environment. We don't have any other details to share, however,

In the general case, importing a resource can't be automated because there are aspects of the process that are unknowable - such as which secrets should be published or consumed, and so on.

This is why we packaged the feature as a command-line tool - asoctl import azure-resource takes care of 90-95% of the process of importing an existing Azure Resource, allowing the user to focus their attention on the complex bits of integration.

For your particular context, with local knowledge you may be able automate things by consuming the importresources library, or just by using the ImportableResource interface.

We're interested to know more about your specific scenario, if you're willing to share.