azurerm_container_registry
- support update replications on demand
#16678
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds more finer grained control on how to update the replications for
azurerm_container_registry
.Previously, any change in the
georeplications
will cause all replications to be recreated. This causes unexpected downtime for replications that are not affected (see #16634). This PR fixes it in way that:Specially for update replications, API currently doesn't support updating the
zoneRedundancy
in place, which makes us have to delete then create it. Also, API has a bug when create a just deleted replication, see: Azure/azure-rest-api-specs#18934. Therefore, I have added a explicit wait in this PR to avoid that.Additionally, during the test I noticed the LIST api of the replication will return the replications in arbitrary order. I have sorted it for the
georeplications
alphabetically during flattening. So that make the plan diff more readable for users (assuming users order their config alphabetically as well). Ideally, it should useSet
instead, but it can't.Fixes #16634.
Test
Additionally, I've locally inspected the API sequence and confirmed it worked as expected.