On 15/04/19 11:01 AM, Bence Romsics wrote:
On Mon, Apr 15, 2019 at 4:39 PM Rabi Mishra <ramishra@redhat.com> wrote:
I think this had been discussed on several occasions[1] before and one of the suggestions from the neutron team was to use compare-and-swap update api [2] to avoid race conditions.
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131020.html [2] https://bugs.launchpad.net/neutron/+bug/1703234
Thank you for your quick answer. I did read that previous discussion and I did not properly understand why compare-and-swap was recommended. To my understanding compare-and-swap allows a client to detect a race with another, but it would not eliminate the races. All clients would have to retry until success and with the current OS::Neutron::ExtraRoute we do actively generate those races. That's why I went in the directions mentioned in my original mail. Am I missing something?
Yes, you have to do it in a loop. So instead of just: * read the current status * add the new route to the data * write back the whole thing you'd need to do: * read the current status and remember the ETag * add the new route to the data * write back the whole thing with If-Match * if the write is rejected with status code 412, go back to the beginning IMHO the best place to implement this would be in neutronclient/openstacksdk and not Heat, because the problem is inherent to the API and exists everywhere. However, I wouldn't reject a fix in Heat. cheers, Zane.