<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Rabi,<br>
<br>
see below<br>
<br>
<div class="moz-cite-prefix">On 12/13/17 11:03 AM, Rabi Mishra
wrote:<br>
</div>
<br>
<blockquote type="cite"
cite="mid:151315580389.3550.2266612269058327464.malone@gac.canonical.com">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<blockquote type="cite">
<pre wrap="">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).</pre>
</blockquote>
<br>
As said:<br>
<br>
<pre wrap="">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.</pre>
<br>
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 - <a
class="moz-txt-link-freetext"
href="http://lists.openstack.org/pipermail/openstack-dev/2017-July/120145.html">http://lists.openstack.org/pipermail/openstack-dev/2017-July/120145.html</a>.
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.<br>
<br>
<blockquote type="cite"
cite="mid:151315580389.3550.2266612269058327464.malone@gac.canonical.com">
<pre wrap="">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'.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks.<br>
<br>
<a class="moz-txt-link-freetext"
href="https://bugs.launchpad.net/heat/+bug/1737567">https://bugs.launchpad.net/heat/+bug/1737567</a><br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</body>
</html>