Through the ARM REST API, I want to read a resource (an NSG) modify it and then write it back. I want the last step (writing it back) to fail if something came along and modified the resource in between my read and my write operation. Is that possible? I see there is an ETAG property when I do a GET, perhaps there is some way to utilize it to make the write fail if the resource is modified?
0
votes
What's your scenario? I.e. how do you know that the change that happened between your read and write takes precedence over yours? Could you lock the resource?
– bmoore-msft
@bmoore-msft my scenario is automating NSG changes (e.g. runbook with webhook). If two changes occur concurrently, I was hoping there is a way to make one fail and then retry the other with an exponential backoff.
– gregjhogan
Ok, but even in that case it's at best a race, right? If I could "lock" the resource for the period of time I'm working on it (which won't actually work, but the idea is the same) - someone could come along immediate after your write and make the change they wanted to make anyway...
– bmoore-msft
@bmoore-msft I wasn't quite specific enough. It isn't a race if part of my retry logic (if someone else modified the list) is to first re-read the list, add the pending change again, and then attempt to save again.
– gregjhogan
Understood - I'm not trying to be provocative, just want to see if I can wrap my head around the scenario and see if there's a platform gap here. There are some properties that cannot be changed once set, but for everything else if you "declare" this is what you want, then that's what the platform will give you - the current state of the resource isn't taken into account. You could GET the current state and do the comparison on your own - that would be pretty simple in REST - would that work in your case?
– bmoore-msft
1 Answers
0
votes
As I known, Azure Table Storage has the ETag in ITableEntity which is used for optimistic concurrency during updates. While the Azure REST API Network Security Groups about etag:
A unique read-only string that changes whenever the resource is updated.
I have tried to leverage Azure Portal and resources.azure.com to simulate the concurrent update operations on my NSG, and I found that there is no concurrency control on the update operation, the configurations would be overrided by the later request.
Per my understanding, there is no build-in feature for you to handle optimistic concurrency. For NSG, I assumed that you would not frequently modify it. So, I think you could try to limit the permission for a few people to update your NSG, or you could build your custom REST API for updating NSG, and get the latest NSG info, then compare the etag with your prior etag to determine that whether the NSG is modified before you update it. Also, you could add your feedback here.
