Discussion: certain resources not being idempotent once marked as secondary

[slavizh]

Just opening a discussion rather flagging this as an issue or feature. There are certain resources that you can create once and after that they are no longer idempotent. They will fail if you try to re-deploy. This is very noticeable in resource that usually act like secondary. For example:

• service bus - when you associate another service bus namespace for disaster recovery to primary basically you no longer can manage the resource as if you redeploy it will fail.
• mysql database server - read replicas can be created but once you try to re-deploy they will fail.

There are probably more resources like these. As you can see these are not deployment stacks issues but will affect the deployment stacks usage.

You can built your templates to deploy them the first time and when you do subsequent deployments you can disable deployment of these resources via input parameter. That solves the problem of being able to initially deploy them in the template but it does not solve the problem with deployment stacks. If you do not want these resources to be deleted you can use detach mode but than you loose idempotency on resources that will no longer be deployed and needs to be deleted. Usually such kind of API problems are not fixed or fixed after years from my experience. If you try to logon support case first you will loose a lot of time until it gets to the right people and after that as long as you have some other workaround to create those like PS or CLI they will say to you to use those workarounds and never commit to fix the problem. Unfortunately this is common problem with Microsoft support. They will commit to fix only if it is very urgent and there is no workaround. should there be some feature of deployment stacks to cover such scenarios or if in those cases using deployment stacks will not be possible, at least in delete mode.

[bmoore-msft]

@slavizh - do you have a short/sample template for one of these cases?

[slavizh]

@bmoore-msft yes, will send it in private

[bmoore-msft]

Which mysql db fails the second time? The master or replica? Here's my understanding...

• deploy master
• deploy replica (all good to this point)
• deploy master again (fails?)

[slavizh]

Deploy master and replica at the same time. Re-deploy master and replica - replica fails. That is why we have a switch that evaluates condition on replica to be deployed or not depending on the input for that switch.

[bmoore-msft]

What's the error you get?

[slavizh]

@bmoore-msft I do not know as the template was not done by me. I will see if I can try and post the error these days.

[bmoore-msft]

@snarkywolverine @apclouds - we may want to open a standing issue for logging these types of issues, and a separate one for delete failures?

[bmoore-msft]

@slavizh - aside from fixing the problem in the RP - do you have thoughts on what we would do from a stacks perspective to help address it?

[slavizh]

@bmoore-msft Fixing the RP is the only option to me. Unfortunately I cannot think of any other way of adding something to stacks without compromising the idea of stacks. For example adding somehow a resource to stacks without having to be in the deployment will compromise the idea of stacks.

[bmoore-msft]

Ok - looks like we're on the same page there - as "slooowwww" as that solution can be I continue to think it's the best one.

I'm going to close this out for now - but for anyone reading this in the future, please feel free to add other resources/scenarios where you encounter idempotency issues.