provider-azure icon indicating copy to clipboard operation
provider-azure copied to clipboard

Upgrading ResourceGroup, VirtualNetwork and Subnet resources to v1beta1

Open muvaf opened this issue 2 years ago • 0 comments

What problem are you facing?

These are the foundational resources of Azure but they are still on v1alphaX level support and they still don't adhere to XRM due to not having provider-specific parameters under spec.forProvider.

We'd like to upgrade them to v1beta1. However, we have an implicit convention of upgrading to v1beta1 only if the resource is fully compliant with the XRM on that date. One reason we have that convention is to differentiate XRM-compliant ones from others and other reason is that we don't yet have conversion webhooks support in Crossplane, so upgrading something to v1beta1 and then making schema-breaking change to get them XRM compliant would involve surgery for users, which we know that almost all provider-azure users would have to do.

How could Crossplane help solve your problem?

The differentiation reason isn't much relevant today since all alpha ones are already XRM-compliant, in fact, these few Azure resources may be the only ones in Crossplane ecosystem that are still not XRM-compliant. For the second one, we plan on getting webhook support implemented in Q1 of 2022 but conversion webhooks will probably come in Q2.

The options are roughly:

  • Keep them v1alpha3 and bump to v1beta1 only when conversion webhooks are ready.
    • This is (more than?) the level of guarantee we make for beta resources anyway.
  • Bump them to v1beta1 without any schema changes today and make them XRM-compliant before v1beta2 or v1 via conversion webhook.
    • Against our convention, but inline with formal Kubernetes API policies; we'd provide the level of support appropriate with the version we mark it.

muvaf avatar Jan 28 '22 11:01 muvaf