matthchr
commented
2 months ago ASO won't ever automatically delete resources under any circumstance.
The only time a resource would be deleted is if you issue kubectl delete (or delete the resource in git and then your gitops engine issues the equivalent of kubectl delete).
For example, with git we can validate schema-level changes, but there are oftentimes changes that would end up re-creating the resource which is not always evident in the PR (e.g., changes to a name param).
ASO will reject changes to the name field of a resource, because that field is immutable in Azure. If you want to delete that resource and create a different one, issue kubectl delete on the resource you no longer want, and create a new YAML corresponding to the new resource (with a new name) and apply it.
We don't currently have any equivalent to Terraform plan. Partially that's because it doesn't fit as well into an operator model as it does into Terraforms model, partially that's because with ASO you (in general) need to do a bit less guessing about what it's actually going to do when compared to Terraform.
Much of the time, viewing the changes in git prior to merging the PR is going to be sufficient. If we were to implement some sort of plan-like approach, ~95% of the time the actual Azure API delta and the ASO delta would look identical, because ASO objects just proxy the Azure API shape most of the time.
There are a few tools/tricks you can have to help protect things even in the abscence of a plan-like approach:
- One you've already identified is to do gitops and examine the git delta before applying it. As mentioned above this gets you ~90+% of the way there.
- You can also make use of annotations like serviceoperator.azure.com/reconcile-policy: detach-on-delete, which says that even if somehow you miss a resource being deleted in your gitops PR reviews, it still won't actually be deleted in Azure. We don't necessarily recommend this for every resource (especially ephemeral ones where you want ASO to be able to delete them), but it might be a good idea to set it on any persistent production infrastructure, especially things like databases.
I don't think we're necessarily opposed to a plan-like feature, but I don't know exactly what it would look like in the context of an operator like ASO, and we'd need to understand what value add it added over standard GitOps which (I think) already mostly covers it.
We're looking to utilize ASO v2 in our org, but one question we have is how to go about validating infrastructure changes prior to deploying? For example, with git we can validate schema-level changes, but there are oftentimes changes that would end up re-creating the resource which is not always evident in the PR (e.g., changes to a name param). What we are looking for is an output similar to a Terraform Plan or an alternative approach to validate such changes prior to the ASO performing actions.