[openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Brandon Logan
brandon.logan at rackspace.com
Thu Apr 17 02:17:14 UTC 2014
Stephen,
Commenting in line below
On 04/16/2014 07:56 PM, Stephen Balukoff wrote:
> Hi y'all!
>
> This is actually a pretty good start for a revision of the Neutron
> LBaaS API.
>
> My feedback on your proposed API v2.0 is actually pretty close to
> Eugene's, with a couple additions:
>
> You say 'only one port and protocol per load balancer', yet I don't
> know how this works. Could you define what a 'load balancer' is in
> this case? (port and protocol are attributes that I would associate
> with a TCP or UDP listener of some kind.) Are you using 'load
> balancer' to mean 'listener' in this case (contrary to previous
> discussion of this on this list and the one defined here
> https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary#Loadbalancer )?
Yes, it could be considered as a Listener according to that
documentation. The way to have a "listener" using the same VIP but
listen on two different ports is something we call VIP sharing. You
would assign a VIP to one load balancer that uses one port, and then
assign that same VIP to another load balancer but that load balancer is
using a different port than the first one. How the backend implements
it is an implementation detail (redudant, I know). In the case of
HaProxy it would just add the second port to the same config that the
first load balancer was using. In other drivers it might be different.
>
> As pointed out, one pool per load balancer breaks any L7 switching
> functionality. SSL and L7 were the two major features that spawned
> this whole discussion about LBaaS a couple months ago, so any solution
> we propose should probably have these features.
Yes we agree one pool per load balancer breaks L7 switching
functionality. However, as I told Eugene, we also came up with a
"content_switching" object that would be a part of the load balancer
root object. In that object it does define multiple pools and rules.
The details of the pools and rules may indeed need some tweaking, but
that doesn't mean this solution breaks the L7 switching requirement.
As for SSL, this absolutely allows SSL. Using the common use case for
SSL Termination:
1. Create an HTTP load balancer listening on port 80.
2. Create an HTTPS load balancer listening on port 443 sharing the same
VIP and pool as the first load balancer. Also, add an SSL
Termination/SSL Decryption object to this 2nd load balancer.
We did not say much about the SSL Termination/SSL Decryption object
because we wanted to make sure it was able to meet other requirements
before we started to discuss that.
>
> Context switching is the *only* reason to have multiple pools per load
> balancer... and I really just don't understand where the "consistency"
> argument between having "a pool" vs. "pools." I don't understand why
> one would think having multiple pools for a load balancer (that
> doesn't need them) would be a desired way to handle this
> "inconsistency" problem. Anyway... There's been discussion of this
> previously here: https://wiki.openstack.org/wiki/Neutron/LBaaS/l7
> ...and I think I can illustrate (via proposed API) a better way to do
> this... (in a nutshell, you need to have an additional object which
> links listeners to pools via a policy or rule. API is going to need to
> have controls to modify these rules.)
>
> I'm not sure I fully understand the requirements behind the "single
> API call" proposal for creating a LBaaS service instance (whatever
> that means). Therefore, for now, I'm going to withhold any judgement
> on this or anything attempting to meet this requirement. Where does
> this need come from, and what are people expecting to see for their
> "single API call"?
The "single API call" is something we do currently use. One reason to
have it is because it is easier to understand from a user standpoint
that creating a fully provisioned load balancer is done in one step at
the /loadbalancers resource instead of having to go to 3 or more
additional resources to do this. Now, since 90% of users will most
likely be using some kind of GUI to do this it might minimize the need
for this, but we still feel that creating less confusion is best.
Another reason we prefer this is because we have experience in an API
that does need to make many calls and steps before a load balancer is
actually up and running. Once the environment all of the load balancers
lived in became more and more dense, the provisioning time increased by
many folds. Once we were able to use an API that used the same backend
and environment but every step was done in one call, the provisioning
time was cut down by a factor of 20. Now this may just be a fluke only
we encounter but I don't see how having a single API create call hurts
anything. The CLI client can still only have options to create a load
balancer in 3 or more steps.
>
> I'd like to take a stab at revising this API to reflect both the
> terminology defined in the glossary here:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary as well as
> addressing features having to do with SSL, L7 and (if y'all will let
> me) HA. I would also work off the requirements documents here:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements
> Features wishlist here:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases
> Moderated by the real-world feature usage here:
> https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc&usp=sharing
> ... to try to create an API which addresses as much of this as
> possible (with appropriate object model diagrams for reference), yet
> still has "sane defaults" for simple use cases.
>
> As an aside, it seems everyone's number one feature request at this
> time is HA. (more so than SSL and L7, yo!)
>
> Note that I certainly won't have this ready for tomorrow's meeting,
> but could probably have a draft to show y'all at next week's meeting
> if y'all think it would be helpful to produce such a thing. Anyway, we
> can discuss this at tomorrow's meeting...
Please take a stab at it, the more ideas we all see the better we can
make the revised API. We can incorporate all the good ideas into one
great API. At least that is the hope
>
> Thanks,
> Stephen
>
>
>
>
> On Wed, Apr 16, 2014 at 4:17 PM, Carlos Garza
> <carlos.garza at rackspace.com <mailto:carlos.garza at rackspace.com>> wrote:
>
>
> On Apr 16, 2014, at 4:31 PM, Eugene Nikanorov
> <enikanorov at mirantis.com <mailto:enikanorov at mirantis.com>> wrote:
>
>> Hi folks,
>>
>> I've briefly looked over the doc.
>>
>> I think whole idea to base the API on Atlas misses the content
>> switching use case, which is very important:
>> We need multiple pools within loadbalancer, and API doesn't seem
>> to allow that.
>> If it would, then you'll face another problem: you need to
>> reference those pools somehow inside the json you use in POST.
>> There are two options here: use names or IDs, both are putting
>> constraints and create complexity for both user of such API and
>> for the implementation.
>>
>> That particular problem becomes worse when it comes to objects
>> which might not have names while it's better to not provide ID in
>> POST and rely on their random generation. E.g. when you need to
>> create references between objects in json input - you'll need to
>> create artificial attributes just for the parser to understand
>> that such input means.
>>
>> So that makes me think that right now a 'single-call API' is not
>> flexible enough to comply with our requirements.
>
> We have demonstrated that you can create loadbalancers in
> separate transactions and in a single call fashion using both
> reference_ids to previous pools and as well as using a transient
> names to create objects in the same single call and reference them
> later on in other objects. The single call API is very flexible in
> that it allows you to create sub objects(We proposed transient ids
> to allow the user to avoid creating duplicate objects with
> different ids) on the fly as well as reference preexisting objects
> by id. The allowance for transient ids is adding flexibility to
> the api not taking away from it as you declared. I would like you
> to really be clear on what "our requirements"? What requirement is
> our single API call violating?
>
> We have thus far attempted to support a single call API that
> doesn't interfere with multiple smaller object creation calls. If
> we are just adding to the API in a demonstrably workable fashion
> what is the real objection.
>
>
>> While I understand that it might be simpler to use such API for
>> some cases, it makes complex configurations fall back to our
>> existing approach which is creating configuration on per object
>> basis.
>> While the problem with complex configurations is not sorted out,
>> I'd prefer if we focus on existing 'object-oriented' approach.
>
> Your basically saying
> P1: "The single API call proposal doesn't support *ALL* complex
> configurations"
> P2: " if the single API proposal doesn't support *ALL* complex
> configurations the proposal should be rejected"
>
> We have demonstrated that the proposed single API call can handle
> complex configurations via transient ids. So we already disagree
> with preposition 1.
>
> We don't agree with preposition 2 either:
> We believe it is unfair to punish the API end user due to the
> religious belief that "The single API calls must support all
> possible configurations or you as the customer can't be allowed to
> use the single API call even for simpler configurations."
>
> We want the single API call proposal to be as useful as possible
> so we are like wise looking at ways to have it solve ALL complex
> configurations and so far we feel transient IDs solve this problem
> already.
>
> Is the real objection that a single API call makes the
> implementation too complex? We are advocating that a single API
> makes it easier on the end user of the API and are of the
> impression that its better to have a complex implementation inside
> our neutron/lbaas code rather then passing that complexity down to
> the end user of the API.
>
> We don't object to multiple smaller object creation
> transactions we just want the addition of having single API call.
>
>
>> On the other hand, without single-call API the rest of proposal
>> seems to be similar to approaches discussed in
>> https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion
> Since you linked the object model proposals could you also
> link the "rest of the proposals" or are you referring to our draft
> as "rest of proposal"?
>
>
>> Thanks,
>> Eugene.
>>
>>
>>
>>
>>
>> On Thu, Apr 17, 2014 at 12:59 AM, Brandon Logan
>> <brandon.logan at rackspace.com
>> <mailto:brandon.logan at rackspace.com>> wrote:
>>
>> Sorry about that. It should be readable now.
>> ------------------------------------------------------------------------
>> *From:* Eugene Nikanorov [enikanorov at mirantis.com
>> <mailto:enikanorov at mirantis.com>]
>> *Sent:* Wednesday, April 16, 2014 3:51 PM
>>
>> *To:* OpenStack Development Mailing List (not for usage
>> questions)
>> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Requirements
>> and API revision progress
>>
>> Hi Brandon,
>>
>> Seems that doc has not been made public, so please share.
>>
>> Thanks,
>> Eugene.
>>
>>
>> On Thu, Apr 17, 2014 at 12:39 AM, Brandon Logan
>> <brandon.logan at rackspace.com
>> <mailto:brandon.logan at rackspace.com>> wrote:
>>
>> Here is Jorge and team's API proposal based on Atlas.
>> The document has some questions and answers about why
>> decisions were made. Feel free to open up a discussion
>> about these questions and answers and really about
>> anything. This can be changed up to fit any flaws or
>> use cases we missed that this would not support.
>>
>> There is a CLI example at the bottom along with a
>> possible L7 switching API model.
>>
>> https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit
>>
>> Thanks,
>> Brandon Logan
>>
>> From: Eugene Nikanorov <enikanorov at mirantis.com
>> <mailto:enikanorov at mirantis.com>>
>> Reply-To: "openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>"
>> <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>
>> Date: Tuesday, April 15, 2014 at 7:00 AM
>> To: "openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>"
>> <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>
>>
>> Subject: Re: [openstack-dev] [Neutron][LBaaS]
>> Requirements and API revision progress
>>
>> Hi Stephen,
>>
>> Thanks for a good summary. Some comments inline.
>>
>>
>> On Tue, Apr 15, 2014 at 5:20 AM, Stephen Balukoff
>> <sbalukoff at bluebox.net <mailto:sbalukoff at bluebox.net>>
>> wrote:
>>
>>
>> So! On this front:
>>
>> 1. Does is make sense to keep filling out use cases
>> in Samuel's document above? I can think of several
>> more use cases that our customers actually use on our
>> current deployments which aren't considered in the 8
>> cases in Samuel's document thus far. Plus nobody has
>> create any use cases from the cloud operator
>> perspective yet.
>>
>>
>> I treat Sam's doc as a source of use cases to triage API
>> proposals. If you think you have use cases that don't fit
>> into existing API or into proposed API, they should
>> certainly be brought to attention.
>>
>>
>> 2. It looks like we've started to get real-world data
>> on Load Balancer features in use in the real world.
>> If you've not added your organization's data, please
>> be sure to do so soon so we can make informed
>> decisions about product direction. On this front,
>> when will we be making these decisions?
>>
>> I'd say we have two kinds of features - one kind is
>> features that affect or even define the object model and API.
>> Other kind are features that are implementable within
>> existing/proposed API or require slight changes/evolution.
>> First kind is the priority: while some of such features
>> may or may not be implemented in some particular release,
>> we need to implement proper infrastructure for them (API,
>> obj model)
>>
>> Oleg Bondarev (he's neutron core) and me are planning and
>> mostly interested to work on implementing generic stuff
>> like API/obj model and adopt haproxy driver to it. So our
>> goal is to make implementation of particular features
>> simpler for contributors and also make sure that proposed
>> design fits in general lbaas architecture. I believe that
>> everyone who wants to see certain feature may start
>> working on it - propose design, participate in
>> discussions and start actually writing the code.
>>
>>
>> 3. Jorge-- I know an action item from the last
>> meeting was to draft a revision of the API (probably
>> starting from something similar to the Atlas API).
>> Have you had a chance to get started on this, and are
>> you open for collaboration on this document at this
>> time? Alternatively, I'd be happy to take a stab at
>> it this week (though I'm not very familiar with the
>> Atlas API-- so my proposal might not look all that
>> similar).
>>
>> +1, i'd like to see something as well.
>>
>>
>> What format or template should we be following to
>> create the API documentation? (I see this here:
>> http://docs.openstack.org/api/openstack-network/2.0/content/ch_preface.html
>> but this seems like it might be a little heavy for
>> an API draft that is likely to get altered
>> significantly, especially given how this discussion
>> has gone thus far. :/ )
>>
>>
>> Agree, that's too heavy for API sketch. I think a set of
>> resources with some attributes plus a few cli calls is
>> what could show the picture.
>>
>> Thanks,
>> Eugene.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> <mailto: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
>> <mailto: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
>> <mailto: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
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
>
> _______________________________________________
> 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/20140416/6ecbbf08/attachment-0001.html>
More information about the OpenStack-dev
mailing list