Open Stack

Hi,

> Wiadomość napisana przez Zane Bitter <zbitter at redhat.com> w dniu 15.04.2019, o godz. 19:02:
> 
> On 15/04/19 11:01 AM, Bence Romsics wrote:
>> On Mon, Apr 15, 2019 at 4:39 PM Rabi Mishra <ramishra at 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.

IMO option 2 provided by Bence is the best one here. This should be fixed in neutron API by making extra routes first class API objects and treat them as router interfaces. DB layer is „ready” for that IMO so it should be handled easy.
All other ways it will just be kind of workaround of the issue. Even if we will fix it in OpenStack SDK and/or neutron client there may be someone who is using API in some other way and will still hit the same issue.

> 
> cheers,
> Zane.
> 

— 
Slawek Kaplonski
Senior software engineer
Red Hat