Open Stack

Eugene,

Thanks for your comments,

See inline:

Susanne


On Mon, Mar 24, 2014 at 4:01 PM, Eugene Nikanorov
<enikanorov at mirantis.com>wrote:

> Hi Susanne,
>
> a couple of comments inline:
>
>
>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>

> As far as I understand these two abstracts, you're talking about making
> LBaaS API more high-level than it is right now.
> I think that was not on our roadmap because another project (Heat) is
> taking care of more abstracted service.
> The LBaaS goal is to provide vendor-agnostic management of load balancing
> capabilities and quite fine-grained level.
> Any higher level APIs/tools can be built on top of that, but are out of
> LBaaS scope.
>
>
[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?


>
>>
>> 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.
>>
>> We have a draft on how we could make Neutron LBaaS take advantage of
>> Libra in the back-end.
>>
>> The details are available at:
>> https://wiki.openstack.org/wiki/Neutron/LBaaS/LBaaS%2Band%2BLibra%2Bintegration%2BDraft
>>
>
> 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.
>

[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.


>
>
>>  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.
>>
> I'm not sure about building it directly into LBaaS, although we can
> discuss it.
>

[Susanne] The idea behind the "managed services" aspect/extensions would be
reusable for other software LB.


> 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.
>
>
[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.


>>
>> 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.
>>
>>
>>
>> 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 (
>> https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy) 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.
>>
> 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.
>

[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?



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 wouldn't want to have a say around
how it is architected.


> 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, swap the floating ip and update the db, etc. and have a new LB
>> running.
>>
>

> 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.
>

[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.

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.



> Thanks,
> Eugene.
>
>
>>
>> Regards Susanne
>>
>> -------------------------------------------
>>
>> Susanne M. Balle
>> Hewlett-Packard
>> HP Cloud Services
>>
>> Please consider the environment before printing this email.
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140324/ac804f57/attachment.html>