On Apr 16, 2014, at 7:56 PM, Stephen Balukoff 
<sbaluk...@bluebox.net<mailto:sbaluk...@bluebox.net>>
 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 )?

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.


    Then I think we should discuss opening up the notion of having multiple 
pools. We have an idea on how to describe L7 routing in the proposal and 
suggested that multiple pools should be applied to content switching. The 
example in the doc shows a rule being made for pool2.  Although I think this 
could be specified in the form of the L7VipPoolAssociation described in
https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#VIP-centric_solution
 I don't think that name should be used. What I'm not feeling good about is 
that the object model on the
that links pools to rules. from this wikipage I still don't have any idea what 
the API calls would look like or what the L7Policy would look like. Perhaps you 
could elaborate on this more.

This was by no means an attempt to submit a proposal for final solution just 
throwing the doc out there so we can see some ideas on the API. So far I'm only 
finding Object models when people are referring to the API. It seems that other 
API proposals exist but no one seems to be showing what the calls would look 
like.

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.

    I guess I'm misunderstanding you. It seemed like you were advocating 
multiple pools be allowed per loadbalancer, from your text  "one pool per load 
balancer breaks any L7 switching functionality."
Are you in favor of multiple pools or a single pool per loadbalancers?


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 appreciate the discussion but all I see in reference to L7 is
API changes
Crud operations for L7Policy, L7Rules and an the Association object which I 
guess joins the two.
We would like to see your idea of what the JSON body for such a request would 
look like.


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 requirement comes from our customers. We currently have a no 
requirement for L7 switching from our customers but we see no objection to 
having having it included into the API. And since your team has a clear 
understanding of this need we are interested in your proposal.



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.

    Although its not documented in our proposal we also have Strong SSL 
requirements from our customers and our team was vetting out what a good API 
solution should look like before we submitted it to the mailing list which lets 
be honest was going to be rejected early on if we didn't which is why you don't 
see it being half baked  in this document we issued today. We would also hope 
that the community would like wise not jump to conclusions and dismiss the 
single API call simply because they don't have a requirement.

    Currently we were thinking of having a DecryptSSL object that could be 
attached to the Listener/LoadBalancer(Depending on what term is agreed apron) 
as well as a ReEncryptSSL object that could be attached to the pool to meet 
item 7 in the doc 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
with content switching on the URI determining which pool to use.  I am 
interested in your SSL proposal.


As an aside, it seems everyone's number one feature request at this time is HA. 
(more so than SSL and L7, yo!)

   I would agree HA tops the list, but I don't think the API proposals are 
ignoring this? I would think HA would be strongly influenced by the low level 
implantation of the (Driver, Provider or what ever you wish to call it) and 
much less so by the API message format discussions.

   I think concerns about HA are really stemming from people desiring an 
implementation that scales has failover capabilities with floating-ips in the 
same network. IE they want an option that lets a LoadBalancer failover its IP 
to another load balancer should the host machine its on via a VM or a physical 
box, process LXC container should fail. It feels at this point the user is 
wanting to associate an IP on two ports on the same neutron network. In the 
real world the heart beat steals the IP of the failed machine by bringing up 
the ip on its interface which causes it to advertise new arp responses since 
the dead node can't. This has strong implications for the low level driver.

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…

    Yes we are very interested in your concrete ideas. So far all we saw on ssl 
is an entry in the vip table of a proposed object model but nothing else.
We would like to hear your ideas.
Thanks,
Stephen




On Wed, Apr 16, 2014 at 4:17 PM, Carlos Garza 
<carlos.ga...@rackspace.com<mailto:carlos.ga...@rackspace.com>> wrote:

On Apr 16, 2014, at 4:31 PM, Eugene Nikanorov 
<enikano...@mirantis.com<mailto:enikano...@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.lo...@rackspace.com<mailto:brandon.lo...@rackspace.com>> wrote:
Sorry about that.  It should be readable now.
________________________________
From: Eugene Nikanorov [enikano...@mirantis.com<mailto:enikano...@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.lo...@rackspace.com<mailto:brandon.lo...@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 <enikano...@mirantis.com<mailto:enikano...@mirantis.com>>
Reply-To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 15, 2014 at 7:00 AM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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 
<sbaluk...@bluebox.net<mailto:sbaluk...@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@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<mailto:OpenStack-dev@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@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

Reply via email to