Add "ignore_changes" support

[MZODEH-se]

Hi,
We have a use case where a Redis Cache is cretaed by ASO.
Once created we have an external support team that need to put some tags manually on the Redis Cache.
But since ASO compares current state with desired state each 30min, the tags get removed.
Support team can't give us the tags in advance since they don't know all of them in advance. Otherwise we could add them when deploying the Redis Cache.

As workaround, when the Redis Cache is deployed we put the annotation "serviceoperator.azure.com/reconcile-policy: skip". But this is not an efficient solution since it brings other issues.

What we want is to have a parameter at the Resource level which allows to ignore changes affecting an attribute of the resource. Something like what is done with Terraform parameter " ignore_changes = [tags]".

Any idea on how to implement this?

Thanks in advance for your support

[matthchr]

Sorry for the slow response, I wanted to make sure that I understood exactly how ignore_changes was implemented for Terraform and it took me a while to get a chance to dig in and understand how exactly it works.

In the short term, can your support team make their updates via Kuberentes? If they change the resource in Kubernetes and it doesn't have the skip annotation set, the tags will correctly get pushed to Azure immediately.

In the longer term, we can talk about implementing this as a feature. It clearly gets pretty heavy use in Terraform and I see the use-case for it here as well, although I do think it's somewhat more awkward in the Kubernetes context than it is in the Terraform context.

The way that Terraform does this is that they start with the existing resource in Azure, and then merge in changes from the user model over the top of that if ignore_changes is not set for that field.

What this basically boils down to is:

1. HTTP GET
2. Modify GET payload with select contents from Terraform files (honoring ignore_changes)
3. HTTP PUT

This is in contrast to what ASO does today, which is:

1. Build HTTP PUT payload based on CR state
2. HTTP PUT

So we would need to universally HTTP GET first, and then have some collection of fields (JSONPath expressions, maybe?) the user could specify which we would then merge into the HTTP PUT payload prior to actually sending it. That would make ASO something like:

1. HTTP GET
2. Build HTTP PUT payload based on CR state
3. Update HTTP PUT payload based on ignore_changes (getting value from HTTP GET instead).
4. HTTP PUT

It's doable but quite a bit of work. I do think there's probably value in doing it but I'd like to see some more community feedback/interest in the topic before we commit to the work.

[MZODEH-se]

Thank you @matthchr for your answer. Very clear.
We will go with the workaround to satisfy our need.
I will keep watchig the RoadMap of ASO to see when you will implement this feature.
Hope the community will have interest in this topic.
Thanks you again for your time.