<div dir="ltr">Hi <span style="font-family:arial,sans-serif;font-size:13px;white-space:nowrap">Susanne,</span><div><span style="font-family:arial,sans-serif;font-size:13px;white-space:nowrap"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;white-space:nowrap">a couple of comments inline:</span></div>
<div class="gmail_extra"><br><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">We would
like to discuss adding the concept of “managed services” to the Neutron LBaaS
either directly or via a Neutron LBaaS plug-in to Libra/HA proxy. The latter
could be a second approach for some of the software load-balancers e.g. HA
proxy since I am not sure that it makes sense to deploy Libra within Devstack
on a single VM.</span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">Currently
users would have to deal with HA, resiliency, monitoring and managing their
load-balancers themselves. As a service provider we are taking a more
managed service approach allowing our customers to consider the LB as a black
box and the service manages the resiliency, HA, monitoring, etc. for them.</span></p></div></blockquote><div>As far as I understand these two abstracts, you're talking about making LBaaS API more high-level than it is right now.</div>
<div>I think that was not on our roadmap because another project (Heat) is taking care of more abstracted service.</div><div>The LBaaS goal is to provide vendor-agnostic management of load balancing capabilities and quite fine-grained level.</div>
<div>Any higher level APIs/tools can be built on top of that, but are out of LBaaS scope.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">We like
where Neutron LBaaS is going with regards to L7 policies and SSL termination
support which Libra is not currently supporting and want to take advantage of
the best in each project.</span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">We have
a draft on how we could make Neutron LBaaS take advantage of Libra in the
back-end. </span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">The
details are available at:<span> </span><a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LBaaS%2Band%2BLibra%2Bintegration%2BDraft" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/LBaaS%2Band%2BLibra%2Bintegration%2BDraft</a></span></p>
</div></blockquote><div> </div><div>I looked at the proposal briefly, it makes sense to me. Also it seems to be the simplest way of integrating LBaaS and Libra - create a Libra driver for LBaaS. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">While
this would allow us to fill a gap short term we would like to discuss the
longer term strategy since we believe that everybody would benefit from having
such “managed services” artifacts built directly into Neutron LBaaS.</span></p></div></blockquote><div>I'm not sure about building it directly into LBaaS, although we can discuss it. For instance, HA is definitely on roadmap and everybody seems to agree that HA should not require user/tenant to do any specific configuration other than choosing HA capability of LBaaS service. So as far as I see it, requirements for HA in LBaaS look very similar to requirements for HA in Libra.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">There
are blueprints on high-availability for the HA proxy software load-balancer and
we would like to suggest implementations that fit our needs as services
providers.</span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">One
example where the managed service approach for the HA proxy load balancer is
different from the current Neutron LBaaS roadmap is around HA and resiliency.
The 2 LB HA setup proposed (<a href="https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy" target="_blank">https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy</a>)
isn’t appropriate for service providers in that users would have to pay for the
extra load-balancer even though it is not being actively used. </span></p></div></blockquote><div>One important idea of the HA is that its implementation is vendor-specific, so each vendor or cloud provider can implement it in the way that suits their needs. So I don't see why particular HA solution for haproxy should be considered as a common among other vendors/providers.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">An
alternative approach is to implement resiliency using a pool of stand-by
load-and preconfigured load balancers own by e.g. LBaaS tenant and assign
load-balancers from the pool to tenants environments. We currently are using
this approach in the public cloud with Libra and it takes approximately 80
seconds for the service to decide that a load-balancer has failed,<span> </span>swap the floating ip and update the
db, etc. and have a new LB running.</span></p></div></blockquote><div>That for sure can be implemented. I only would recommend to implement such kind of management system out of Neutron/LBaaS tree, e.g. to only have client within Libra driver that will communicate with the management backend. </div>
<div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif"> </span></p>
<p class="MsoNormal" style="background-repeat:initial initial"><span style="font-size:9pt;font-family:Arial,sans-serif">Regards
Susanne </span></p>
<p class="MsoNormal"><a name="144f51ae30af20f8__MailAutoSig"><span style="font-size:9pt;font-family:Arial,sans-serif">------------------------------------------- </span></a></p>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Arial,sans-serif">Susanne M. Balle <br>
Hewlett-Packard <br>
HP Cloud Services </span></p>
<p class="MsoNormal"><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(0,176,80)">Please consider the environment
before printing this email.</span><span style="font-size:9pt;font-family:Arial,sans-serif;color:rgb(34,30,31)"> </span></p>
<p class="MsoNormal"> </p></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>