Add Azure ASO CRDs

[afarbos]

PR Checklist

• I have used the CRD Extractor tool to generate these CRDs

Generated with:

kind create cluster && \
  helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --set installCRDs=true --wait --wait-for-jobs && \
  helm install aso2 aso2/azure-service-operator --create-namespace --namespace=azureserviceoperator-system --set crdPattern='*' --wait --wait-for-jobs && \
  ./Utilities/crd-extractor.sh && \
  cp -r $HOME/.datree/crdSchemas/ . && \
  kind delete cluster && \
  git add $(ls -1 *azure.com/* | grep -vE  '^.+storage.json$') && \
  git commit -m "Add Azure ASO CRDs"

[eyarz]

From the naming convention, it looks like some of it is auto-generated (e.g., api_v1api20220801storage).
Do you have a link to the original CRD to check if those are validated schemas?

[afarbos]

From the naming convention, it looks like some of it is auto-generated (e.g., api_v1api20220801storage). Do you have a link to the original CRD to check if those are validated schemas?

I found the documentation https://azure.github.io/azure-service-operator/design/versioning/ So yes storage are auto-generated. Do you want me to remove them?

[eyarz]

Yes, please remove everything that is auto-generated 😅

[afarbos]

Yes, please remove everything that is auto-generated 😅

Done! Updated the CLI to generate this also.

[eyarz]

It looks like there are still some auto-generated CRs included in the PR.

[eyarz]

@afarbos just thinking out loud here.

As you know, the Azure ASO CRDs include over 400 Custom Resources.
If the CR names are generated with a timestamp, that means every time you update those CRs, you'll need to add 400+ new CRs instead of simply updating the existing ones.

After just a few updates, we could end up with thousands of CRs just for Azure ASO. This could significantly impact the entire repo—making it much heavier and potentially causing issues for anyone trying to pull CRs due to network limitations or GitHub performance.

Just something to consider as we look at long-term scalability.

[afarbos]

@afarbos just thinking out loud here.

As you know, the Azure ASO CRDs include over 400 Custom Resources. If the CR names are generated with a timestamp, that means every time you update those CRs, you'll need to add 400+ new CRs instead of simply updating the existing ones.

After just a few updates, we could end up with thousands of CRs just for Azure ASO. This could significantly impact the entire repo—making it much heavier and potentially causing issues for anyone trying to pull CRs due to network limitations or GitHub performance.

Just something to consider as we look at long-term scalability.

Are you referring to Azure/azure-service-operator#2920, I don't think it would apply to git here no?

I would say they do generate more versions, however this is only with new features meaning they don't just generate a new timestamp just without purpose. This is linked with api versions.