Open Stack

Hi Rabi,

see below

On 12/13/17 11:03 AM, Rabi Mishra wrote:

>> if Heat will provide a way to choose provider (neutron-lbaas or octavia), then customers will continue to use neutron-lbaas as long as
>> it will be required, with their specific drivers (haproxy, F5, A10,
>> etc), gradually migrating to Octavia when time will come.
> Heat already provides that, though it uses neutron lbaas api extenstions
> and not the octavia API (you've to set the service provider for lbaas
> config ex. service_provider =
> LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default).

As said:

Octavia is properly returning a 409 HTTP
status code telling the caller that the load balancer is in an
immutable state and the user should try again.

The issue is neutron-lbaas has some fundamental issues with it's
object locking that would require a full re-write to correct.
neutron-lbaas is not using transactions and locking correctly, so it
is allowing your second request through even though the load balancer
is/should be locked on the first request.


which means, that neutron-lbaas unsuitable for automated operations 
(high operations rate) on same objects if, for some reasons, provider 
asks for delay. I confirm the issue, described here - 
http://lists.openstack.org/pipermail/openstack-dev/2017-July/120145.html. 
It's not Heat's issue, it's neutron-lbaas issue and, while neutron-lbaas 
has such kind of problems, relying on it is undesirable.

> We would probably not like to have the logic in the resources to call
> two different api endpoints based on the 'provider' choice in resource
> properties and then provide more functionality for the ones using
> 'octavia'.

What I'm talking about is not replacing existing resources and not 
expanding functionality, but provide the same functionality using the 
same set of resources using two different providers. It's, IMHO, the 
easiest and fastest way to start support Octavia and work around current 
neutron-lbaas issues.

Yes, Octavia provides superset of current neutron-lbaas API and said 
above doesn't cancel idea to create another set of resources. If Heat 
will provide basic set of functions within basic LBaaS framework and, 
sometimes, richer set within "NG LBaaS" framework - the only I can say: 
it will be great.

Thanks.

https://bugs.launchpad.net/heat/+bug/1737567


-- 
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171213/a09e33e4/attachment.html>