Right, I was just pointing out that solving this in os-vif isn't enough in
this particular case since neutron can't use it so it's slightly different
than the os-brick situation. We have to reason about what two different
code paths will do.
On Aug 29, 2016 6:41 AM, "Sean Dague" wrote:
> On 08/2
On 08/29/2016 08:29 AM, Kevin Benton wrote:
> Sort of. The neutron agent code doesn't use os-vif because the os-vif
> devs indicated that neutron's vif plugging code wasn't a use case they
> cared about [1].
>
> So if we did generalize os-vif to work with the neutron agents then it
> would be two
Sort of. The neutron agent code doesn't use os-vif because the os-vif devs
indicated that neutron's vif plugging code wasn't a use case they cared
about [1].
So if we did generalize os-vif to work with the neutron agents then it
would be two calling the same locked code. But at this point it's jus
On 08/26/2016 05:23 PM, Armando M. wrote:
> Folks,
>
> Today I spotted [1]. It turns out Neutron and Nova might be racing
> trying to set up the bridge to provide VM with connectivity/dhcp. In the
> observed failure mode, os-vif fails in [2].
>
> I suppose we might need to protect the bridge crea
Folks,
Today I spotted [1]. It turns out Neutron and Nova might be racing trying
to set up the bridge to provide VM with connectivity/dhcp. In the observed
failure mode, os-vif fails in [2].
I suppose we might need to protect the bridge creation and make it handle
the potential exception. We woul
