<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>
<div>
<div>Hey Susanne,</div>
<div><br>
</div>
<div>I think it makes sense to group drivers by each LB software. For example, there would be a driver for HAProxy, one for Citrix's Netscalar, one for Riverbed's Stingray, etc. One important aspect about Openstack that I don't want us to forget though is that
a tenant should be able to move between cloud providers at their own will (no vendor lock-in). The API contract is what allows this. The challenging aspect is ensuring different drivers support the API contract in the same way. What components should drivers
share is also and interesting conversation to be had.</div>
<div><br>
</div>
<div>
<div>Cheers,</div>
<div style="font-family: Calibri, sans-serif; "><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">--Jorge</font></font></div>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Susanne Balle <<a href="mailto:sleipnir012@gmail.com">sleipnir012@gmail.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, March 25, 2014 6:59 AM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">John, Brandon, <br>
<br>
<div>I agree that we cannot have a multitude of drivers doing the same thing or close to because then we end-up in the same situation as we are today where we have duplicate effort and technical debt. </div>
<div><br>
</div>
<div>The goal would be here to be able to built a framework around the drivers that would allow for resiliency, failover, etc...</div>
<div><br>
</div>
<div>If the differentiators are in higher level APIs then we can have one a single driver (in the best case) for each software LB e.g. HA proxy, nginx, etc. </div>
<div><br>
</div>
<div>Thoughts?<br>
</div>
<div><br>
</div>
<div>Susanne</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Mar 24, 2014 at 11:26 PM, John Dewey <span dir="ltr">
<<a href="mailto:john@dewey.ws" target="_blank">john@dewey.ws</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I have a similar concern. The underlying driver may support different functionality, but the differentiators need exposed through the top level API.</div>
<div><br>
</div>
<div>I see the SSL work is well underway, and I am in the process of defining L7 scripting requirements. However, I will definitely need L7 scripting prior to the API being defined.</div>
<div>Is this where vendor extensions come into play? I kinda like the route the Ironic guy safe taking with a “vendor passthru” API. </div>
<span class="HOEnZb"><font color="#888888">
<div><br>
</div>
<div>John</div>
</font></span>
<div class="HOEnZb">
<div class="h5">
<div></div>
<p style="color:#a0a0a8">On Monday, March 24, 2014 at 3:17 PM, Brandon Logan wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span>
<div>
<div>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma">Creating a separate driver for every new need brings up a concern I have had. If we are to implement a separate driver for every need then the permutations are endless and may cause a lot drivers
and technical debt<span style="font-size:10pt">. If someone wants an ha-haproxy driver then great. What if they want it to be scalable and/or HA, is there supposed to be scalable-ha-haproxy, scalable-haproxy, and ha-haproxy drivers? Then what if instead
of doing spinning up processes on the host machine we want a nova VM or a container to house it? As you can see the permutations will begin to grow exponentially. I'm not sure there is an easy answer for this. Maybe I'm worrying too much about it because
hopefully most cloud operators will use the same driver that addresses those basic needs, but worst case scenarios we have a ton of drivers that do a lot of similar things but are just different enough to warrant a separate driver.</span>
<div>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font face="Tahoma" color="#000000"><b>From:</b> Susanne Balle [<a href="mailto:sleipnir012@gmail.com" target="_blank">sleipnir012@gmail.com</a>]<br>
<b>Sent:</b> Monday, March 24, 2014 4:59 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and "managed services"<br>
</font><br>
</div>
<div>
<div dir="ltr">
<div>Eugene,</div>
<div><br>
</div>
<div>Thanks for your comments,</div>
<div><br>
</div>
<div>See inline:</div>
<div><br>
</div>
<div>Susanne</div>
<div><br>
</div>
<div><br>
</div>
<div>On Mon, Mar 24, 2014 at 4:01 PM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
</div>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">Hi <span style="font-size: 13px; white-space: nowrap; font-family: arial, sans-serif; ">Susanne,</span>
<div><span style="font-size: 13px; white-space: nowrap; font-family: arial, sans-serif; "><br>
</span></div>
<div><span style="font-size: 13px; white-space: nowrap; font-family: arial, sans-serif; ">a couple of comments inline:</span></div>
<div><br>
<br>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; "> </span></p>
<p style="margin:0px"><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 style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; "> </span></p>
<p style="margin:0px"><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>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div> </div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<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>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; ">[Susanne] Yes. Libra currently has some internal APIs that get triggered when an action needs to happen. We would like similar functionality in Neutron LBaaS so the user doesn’t
have to manage the load-balancers but can consider them as black-boxes. Would it make sense to maybe consider integrating Neutron LBaaS with heat to support some of these use cases? </span></p>
</div>
<div> <br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; "> </span></p>
<p style="margin:0px"><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 style="margin:0px"><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 style="margin:0px"><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>
</div>
</blockquote>
<div> </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>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; ">[Susanne] Yes that would be the short team solution to get us where we need to be. But We do not want to continue to enhance Libra. We would like move to Neutron LBaaS and
not have duplicate efforts.</span></p>
</div>
<div> <br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div>
<div> </div>
<blockquote type="cite">
<div>
<div dir="ltr">
<p style="margin:0px"><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>
</div>
</blockquote>
</div>
<div>I'm not sure about building it directly into LBaaS, although we can discuss it.
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; ">[Susanne] The idea behind the “managed services” aspect/extensions would be reusable for other software LB. </span></p>
</div>
<div> </div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div>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>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; ">[Susanne] Yes. Libra works well for us in the public cloud but we would like to move to Neutron LBaaS and not have duplicate efforts: Libra and Neutron LBaaS. We were hoping
to be able to take the best of Libra and add it to Neutron LBaaS and help shape Neutron LBaaS to fit a wider spectrum of customers/users.</span></p>
</div>
<div><br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div>
<blockquote type="cite">
<div>
<div dir="ltr">
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; "> </span></p>
<p style="margin:0px"><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 style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; "> </span></p>
<p style="margin:0px"><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>
</div>
</blockquote>
</div>
<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>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; ">[Susanne] Are you saying that we should create a driver that would be a peer to the current loadbalancer/ ha-proxy driver? So for example loadbalancer/managed-ha-proxy (please
don’t get hung-up on the name I picked) would be a driver we would implement to get our interaction with a pool of stand-by load-and preconfigured load balancers instead of the 2 LB HA servers? And it would be part of the Neutron LBaaS branch?
</span></p>
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; "> </span></p>
<p style="margin:0px"><font face="Arial,sans-serif"><span style="font-size:9pt">I am assuming that blueprints need to be approved before the feature is accepted into a release. Then the feature is implemented and accepted by the core members into the main repo.
What the process would we have to follow if we wanted to get such a driver into Neutron LBaaS? It is hard to imagine that even thought it would be a “vendor-specific ha-proxy” driver that people in the Neutron LBaaS team </span><span style="font-size:12px">wouldn't</span><span style="font-size:9pt"> want
to have a say around how it is architected.</span></font></p>
</div>
<div><br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div>
<div><br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<p style="margin:0px"><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>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div> </div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<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>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[Susanne] Again this would only be a short term solution since as we move forward and want to contribute new features it would result in duplication of efforts because the features might need to be done in Libra and not Neutron LBaaS. </div>
<div><br>
</div>
<div>In the longer term I would like to discuss how we make Neutron LBaaS have features that are a little friendlier towards service providers' use cases. It is very important to us that services like the LBaaS service is viewed as a managed service e.g. black-box
to our customers. </div>
<div><br>
</div>
<div><br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div>
<div>
<div><br>
</div>
<div>Thanks,</div>
<div>Eugene.</div>
<div><br>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; "> </span></p>
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; ">Regards Susanne </span></p>
<p style="margin:0px"><a name="144f74b2b6a2a811_144f5b4d711c94c0_144f51ae30af20f8__MailAutoSig"><span style="font-size: 9pt; font-family: Arial, sans-serif; ">-------------------------------------------
</span></a></p>
<p style="margin:0px"><span style="font-size: 9pt; font-family: Arial, sans-serif; ">Susanne M. Balle
<br>
Hewlett-Packard <br>
HP Cloud Services </span></p>
<p style="margin:0px"><span style="font-size: 9pt; color: rgb(0, 176, 80); font-family: Arial, sans-serif; ">Please consider the environment before printing this email.</span><span style="font-size: 9pt; color: rgb(34, 30, 31); font-family: Arial, sans-serif; "></span></p>
<p style="margin:0px"> </p>
</div>
<br>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>_______________________________________________</div>
<div>OpenStack-dev mailing list</div>
<div><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></div>
<div><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></div>
</div>
</div>
</span></blockquote>
<div><br>
</div>
</div>
</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>
</div>
</span>
</body>
</html>