I have a similar concern. The underlying driver may support different functionality, but the differentiators need exposed through the top level API.
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. Is this where vendor extensions come into play? I kinda like the route the Ironic guy safe taking with a “vendor passthru” API. John On Monday, March 24, 2014 at 3:17 PM, Brandon Logan wrote: > 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. 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. > From: Susanne Balle [sleipnir...@gmail.com (mailto:sleipnir...@gmail.com)] > Sent: Monday, March 24, 2014 4:59 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and > "managed services" > > Eugene, > > Thanks for your comments, > > See inline: > > Susanne > > > On Mon, Mar 24, 2014 at 4:01 PM, Eugene Nikanorov <enikano...@mirantis.com > (mailto:enikano...@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@lists.openstack.org > > > (mailto:OpenStack-dev@lists.openstack.org) > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org (mailto:OpenStack-dev@lists.openstack.org) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
