Add retries to Resource Group deletion #74
Conversation
In some cases, the resource group can't be deleted immediately. We need to wait until all resources inside it are completely destroyed. Add retries with a 5-second delay, with a maximum of 40 retries.
|
lgtm |
| @@ -16,13 +16,12 @@ | |||
| resource_group: "{{ azure_manage_resource_group_name }}" | |||
| with_items: "{{ result.locks }}" | |||
|
|
|||
There was a problem hiding this comment.
Hi Nir,
The original wait_for 10 seconds was because it sometimes take a bit for a the lock to go away after deleting it right? I think it would be better to do the retry on a new lock_info task inside the above block. This way we wait for the lock to go away only when we actually delete the lock. If the below resource_group delete fails for another reason then the lock we end up retrying for a long time instead of just failing right away,
What do you think?
There was a problem hiding this comment.
I added the retries here in order to allow deleting the resource group in case of the following cases:
- Its take time for the lock to be actual removed
- Its takes time for resource inside the rg to be actual destroyed (related to the discussion we had here)
Solving the issue this way would solve also the same issue we might with other resources that might take longer time to delete.
In case user try to delete none empty resource group without indicating the "force" flag, it will wait 200 seconds, is it acceptable trade-off?
Any suggestion how to solve the second point, in case we use your suggestion for the first one?
There was a problem hiding this comment.
Thanks for the explanation. I think your solution is a good compromise considering.
In some cases, the resource group can't be deleted immediately.
We need to wait until all resources inside it are completely destroyed.
Add retries with a 5-second delay, with a maximum of 40 retries.