Azure
onlyIfModified decorator - deploy only if specified resource properties are different than currently deployed resource properties
Is your feature request related to a problem? Please describe.
The recently introduced onlyIfNotExists is very nice, but IMHO only useful for resource that one is 100% sure would never change. There are arguably some such resource, like Microsoft.ServiceNetworking/trafficControllers (which simply has no properties), but even that is not guaranteed in future ARM API versions (e.g. some property could be added).
Honestly I'm not sure I would ever use this decorator, because I find it too risky - I change some property, deploy and everything seemingly works, except the property was never updated... Sure, there would be a onlyIfModified decoration above the resource, but this could very easily be missed - there might be a lot of properties so it's like 100 lines above, or it's modified by people who aren't bicep experts, or people don't understand this is the behavior (AFAIK it's not even currently documents)...
Describe the solution you'd like
Something like onlyIfModified would be far more useful in my view - if I changed my resource, everything is deployed normally, and I can be sure my change is applied. And if I didn't, the operation is treated as a no-op and time is wasted (or worse, needless failure is encountered). The abovementioned resource is a great example for that as well - at the time of writing, Microsoft.ServiceNetworking/trafficControllers will do a rolling upgrade even if nothing has changed, which actually takes longer than the initial deployment! (not to mention it could possibly fail)
I realize the implementation won't be trivial, because some properties are readonly / auto-generated at the back end, so even if all possible properties were specified in the bicep, they would not 100% match the deployed resource. But I wonder whether some intelligent "subset" check (which is aware of complex objects and arrays) could do the trick? I would prefer to err on the side of caution, so a solution that will always deploy if a property changed, but only most of the time (best-effort) would be a no-op if it didn't, would be good enough in my book.
I totally agree with Ohad. onlyIfNotExists is too risky to use on production systems, and onlyIfModified is what most people probably need.
Another alternative is to have a way to condition the use of onlyIfNotExist. Meaning, assume we usually deploy with OnlyIfNotExist, but once in a while we would like a Full deployment to make sure everything is up to date (assuming onlyIfModified isn't supported). So having a way to apply onlyIfNotExists conditionally can mitigate this slightly.
@onlyIfNotModified would be a wonderful feature in light of the fact that most azure resource providers fail to provide idempotency.
One possible implementation would be to perform a "what-if" deployment of the resource to check if there are any changes required.
The caveat is that what-if still requires write action so the deployer needs full permissions at time of check.
An alternative/complementary solution would be a "non-exploding" reference() function (only read required) that grants developers the flexibility to implement whatever conditionals their scenario demands.
