Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Folks, As we're discussing single-call approach, I think it would be helpful to actually implement such API (e,g. practically, in the code) and see how it works, how compatibility is maintained and such. I think you could start with basic features available for single call - e.g. single vip and single pool (as supported by existing API) In other words, let's relax the requirement of supporting everything within one call (it should be the goal eventually), but as a first step something more simple is enough. Basically I would prefer if there was not a competition between API styles, so I'm strongly against versioning. Let's do it side by side, if single-call API proves to work well - it will be a nice addition for those who expect it. Thanks, Eugene. On Fri, Apr 18, 2014 at 6:36 AM, Brandon Logan brandon.lo...@rackspace.comwrote: We look forward to your proposal and I hope that does get us closer (if not all the way to) an agreed upon revision. Also, thank you for taking the time to fully understand our thought processes on some of the features we want and decisions we made in the proposal. Thanks, Brandon On 04/17/2014 09:01 PM, Stephen Balukoff wrote: Hi Brandon, Yep! I agree that both those definitions are correct: It all depends on context. I'm usually OK with going with whatever definition is in popular use by the user-base. However, load balancer as a term is so ambiguous among people actually developing a cloud load balancing system that a definition or more specific term is probably called for. :) In any case, all I'm really looking for is a glossary of defined terms attached to the API proposal, especially for terms like this that can have several meanings depending on context. (That is to say, I don't think it's necessary to define IP address for example-- unless, say, the distinction between IPv4 or IPv6 becomes important to the conversation somehow.) In any case note that I actually like your API thus far and think it's a pretty good start: Y'all put forth the laudable effort to actually create it, there's obviously a lot of forethought put into your proposal, and that certainly deserves respect! In fact, my team and I will probably be building off of what you've started in creating our proposal (which, again, I hope to have in a showable state before next week's meeting, and which I'm anticipating won't be the final form this API revision takes anyway.) Thanks, Stephen There are only two truly difficult problems in computer science: Naming things, cache invalidation, and off-by-one errors. On Thu, Apr 17, 2014 at 6:31 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Stephen, Thanks for elaborating on this. I agreed and still do that our proposal's load balancer falls more in line with that glossary's term for listener and now can see the discrepancy with load balancer. Yes, in this case the term load balancer would have to be redefined, but that doesn't mean it is the wrong thing to do. I've always been on the side of the Load Balancing as a Service API using a root object called a load balancer. This just really makes sense to me and others, but obviously it doesn't for everyone. However, in our experience end users just understand the service better when the service takes in load balancer objects and returns load balancer objects. Also, since it has been tasked to defined a new API we felt that it was implied that some definitions were going to change, especially those that are subjective. There are definitely many definitions of a load balancer. Is a load balancer an appliance (virtual or physical) that load balances many protocols and ports and is it also one that load balances a single protocol on a single port? I would say that is definitely subjective. Obviously I, and others, feel that both of those are true. I would like to hear arguments as to why one of them is not true, though. Either way, we could have named that object a sqonkey and given a definition in that glossary. Now we can all agree that while that word is just an amazing word, its a terrible name to use in any context for this service. It seems to me that an API can define and also redefine subjective terms. I'm glad you don't find this as a deal breaker and are okay with redefining the term. I hope we all can come to agreement on an API and I hope it satisfies everyone's needs and ideas of a good API. Thanks, Brandon On 04/17/2014 07:03 PM, Stephen Balukoff wrote: Hi Brandon! Per the meeting this morning, I seem to recall you were looking to have me elaborate on why the term 'load balancer' as used in your API proposal is significantly different from the term 'load balancer' as used in the glossary at: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary As promised, here's my elaboration on that: The glossary above states: An object that represent a logical load balancer that may
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Hi Brandon! Per the meeting this morning, I seem to recall you were looking to have me elaborate on why the term 'load balancer' as used in your API proposal is significantly different from the term 'load balancer' as used in the glossary at: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary As promised, here's my elaboration on that: The glossary above states: An object that represent a logical load balancer that may have multiple resources such as Vips, Pools, Members, etc.Loadbalancer is a root object in the meaning described above. and references the diagram here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution On that diagram, it's clear that VIPs, etc. are subordinate objects to a load balancer. What's more, attributes like 'protocol' and 'port' are not part of the load balancer object in that diagram (they're part of a 'VIP' in one proposed version, and part of a 'Listener' in the others). In your proposal, you state only one port and one protocol per load balancer, and then later (on page 9 under GET /vips) you show that a vip may have many load balancers associated with it. So clearly, load balancer the way you're using it is subordinate to a VIP. So in the glossary, it sounds like the object which has a single port and protocol associated with it that is subordinate to a VIP: A listener. Now, I don't really care if y'all decide to re-define load balancer from what is in the glossary so long as you do define it clearly in the proposal. (If we go with your proposal, it would then make sense to update the glossary accordingly.) Mostly, I'm just trying to avoid confusion because it's exactly these kinds of misunderstandings which have stymied discussion and progress in the past, eh. Also-- I can guess where the confusion comes from: I'm guessing most customers refer to a service which listens on a tcp or udp port, understands a specific protocol, and forwards data from the connecting client to some back-end server which actually services the request as a load balancer. It's entirely possible that in the glossary and in previous discussions we've been mis-using the term (like we have with VIP). Personally, I suspect it's an overloaded term that in use in our industry means different things depending on context (and is probably often mis-used by people who don't understand what load balancing actually is). Again, I care less about what specific terms we decide on so long as we define them so that everyone can be on the same page and know what we're talking about. :) Stephen On Wed, Apr 16, 2014 at 7:17 PM, Brandon Logan brandon.lo...@rackspace.comwrote: 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. -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Stephen, Thanks for elaborating on this. I agreed and still do that our proposal's load balancer falls more in line with that glossary's term for listener and now can see the discrepancy with load balancer. Yes, in this case the term load balancer would have to be redefined, but that doesn't mean it is the wrong thing to do. I've always been on the side of the Load Balancing as a Service API using a root object called a load balancer. This just really makes sense to me and others, but obviously it doesn't for everyone. However, in our experience end users just understand the service better when the service takes in load balancer objects and returns load balancer objects. Also, since it has been tasked to defined a new API we felt that it was implied that some definitions were going to change, especially those that are subjective. There are definitely many definitions of a load balancer. Is a load balancer an appliance (virtual or physical) that load balances many protocols and ports and is it also one that load balances a single protocol on a single port? I would say that is definitely subjective. Obviously I, and others, feel that both of those are true. I would like to hear arguments as to why one of them is not true, though. Either way, we could have named that object a sqonkey and given a definition in that glossary. Now we can all agree that while that word is just an amazing word, its a terrible name to use in any context for this service. It seems to me that an API can define and also redefine subjective terms. I'm glad you don't find this as a deal breaker and are okay with redefining the term. I hope we all can come to agreement on an API and I hope it satisfies everyone's needs and ideas of a good API. Thanks, Brandon On 04/17/2014 07:03 PM, Stephen Balukoff wrote: Hi Brandon! Per the meeting this morning, I seem to recall you were looking to have me elaborate on why the term 'load balancer' as used in your API proposal is significantly different from the term 'load balancer' as used in the glossary at: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary As promised, here's my elaboration on that: The glossary above states: An object that represent a logical load balancer that may have multiple resources such as Vips, Pools, Members, etc.Loadbalancer is a root object in the meaning described above. and references the diagram here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution On that diagram, it's clear that VIPs, etc. are subordinate objects to a load balancer. What's more, attributes like 'protocol' and 'port' are not part of the load balancer object in that diagram (they're part of a 'VIP' in one proposed version, and part of a 'Listener' in the others). In your proposal, you state only one port and one protocol per load balancer, and then later (on page 9 under GET /vips) you show that a vip may have many load balancers associated with it. So clearly, load balancer the way you're using it is subordinate to a VIP. So in the glossary, it sounds like the object which has a single port and protocol associated with it that is subordinate to a VIP: A listener. Now, I don't really care if y'all decide to re-define load balancer from what is in the glossary so long as you do define it clearly in the proposal. (If we go with your proposal, it would then make sense to update the glossary accordingly.) Mostly, I'm just trying to avoid confusion because it's exactly these kinds of misunderstandings which have stymied discussion and progress in the past, eh. Also-- I can guess where the confusion comes from: I'm guessing most customers refer to a service which listens on a tcp or udp port, understands a specific protocol, and forwards data from the connecting client to some back-end server which actually services the request as a load balancer. It's entirely possible that in the glossary and in previous discussions we've been mis-using the term (like we have with VIP). Personally, I suspect it's an overloaded term that in use in our industry means different things depending on context (and is probably often mis-used by people who don't understand what load balancing actually is). Again, I care less about what specific terms we decide on so long as we define them so that everyone can be on the same page and know what we're talking about. :) Stephen On Wed, Apr 16, 2014 at 7:17 PM, Brandon Logan brandon.lo...@rackspace.com mailto:brandon.lo...@rackspace.com wrote: 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
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Hi Brandon, Yep! I agree that both those definitions are correct: It all depends on context. I'm usually OK with going with whatever definition is in popular use by the user-base. However, load balancer as a term is so ambiguous among people actually developing a cloud load balancing system that a definition or more specific term is probably called for. :) In any case, all I'm really looking for is a glossary of defined terms attached to the API proposal, especially for terms like this that can have several meanings depending on context. (That is to say, I don't think it's necessary to define IP address for example-- unless, say, the distinction between IPv4 or IPv6 becomes important to the conversation somehow.) In any case note that I actually like your API thus far and think it's a pretty good start: Y'all put forth the laudable effort to actually create it, there's obviously a lot of forethought put into your proposal, and that certainly deserves respect! In fact, my team and I will probably be building off of what you've started in creating our proposal (which, again, I hope to have in a showable state before next week's meeting, and which I'm anticipating won't be the final form this API revision takes anyway.) Thanks, Stephen There are only two truly difficult problems in computer science: Naming things, cache invalidation, and off-by-one errors. On Thu, Apr 17, 2014 at 6:31 PM, Brandon Logan brandon.lo...@rackspace.comwrote: Stephen, Thanks for elaborating on this. I agreed and still do that our proposal's load balancer falls more in line with that glossary's term for listener and now can see the discrepancy with load balancer. Yes, in this case the term load balancer would have to be redefined, but that doesn't mean it is the wrong thing to do. I've always been on the side of the Load Balancing as a Service API using a root object called a load balancer. This just really makes sense to me and others, but obviously it doesn't for everyone. However, in our experience end users just understand the service better when the service takes in load balancer objects and returns load balancer objects. Also, since it has been tasked to defined a new API we felt that it was implied that some definitions were going to change, especially those that are subjective. There are definitely many definitions of a load balancer. Is a load balancer an appliance (virtual or physical) that load balances many protocols and ports and is it also one that load balances a single protocol on a single port? I would say that is definitely subjective. Obviously I, and others, feel that both of those are true. I would like to hear arguments as to why one of them is not true, though. Either way, we could have named that object a sqonkey and given a definition in that glossary. Now we can all agree that while that word is just an amazing word, its a terrible name to use in any context for this service. It seems to me that an API can define and also redefine subjective terms. I'm glad you don't find this as a deal breaker and are okay with redefining the term. I hope we all can come to agreement on an API and I hope it satisfies everyone's needs and ideas of a good API. Thanks, Brandon On 04/17/2014 07:03 PM, Stephen Balukoff wrote: Hi Brandon! Per the meeting this morning, I seem to recall you were looking to have me elaborate on why the term 'load balancer' as used in your API proposal is significantly different from the term 'load balancer' as used in the glossary at: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary As promised, here's my elaboration on that: The glossary above states: An object that represent a logical load balancer that may have multiple resources such as Vips, Pools, Members, etc.Loadbalancer is a root object in the meaning described above. and references the diagram here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution On that diagram, it's clear that VIPs, etc. are subordinate objects to a load balancer. What's more, attributes like 'protocol' and 'port' are not part of the load balancer object in that diagram (they're part of a 'VIP' in one proposed version, and part of a 'Listener' in the others). In your proposal, you state only one port and one protocol per load balancer, and then later (on page 9 under GET /vips) you show that a vip may have many load balancers associated with it. So clearly, load balancer the way you're using it is subordinate to a VIP. So in the glossary, it sounds like the object which has a single port and protocol associated with it that is subordinate to a VIP: A listener. Now, I don't really care if y'all decide to re-define load balancer from what is in the glossary so long as you do define it clearly in the proposal. (If we go with your proposal, it would then make sense to update the glossary accordingly.)
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
We look forward to your proposal and I hope that does get us closer (if not all the way to) an agreed upon revision. Also, thank you for taking the time to fully understand our thought processes on some of the features we want and decisions we made in the proposal. Thanks, Brandon On 04/17/2014 09:01 PM, Stephen Balukoff wrote: Hi Brandon, Yep! I agree that both those definitions are correct: It all depends on context. I'm usually OK with going with whatever definition is in popular use by the user-base. However, load balancer as a term is so ambiguous among people actually developing a cloud load balancing system that a definition or more specific term is probably called for. :) In any case, all I'm really looking for is a glossary of defined terms attached to the API proposal, especially for terms like this that can have several meanings depending on context. (That is to say, I don't think it's necessary to define IP address for example-- unless, say, the distinction between IPv4 or IPv6 becomes important to the conversation somehow.) In any case note that I actually like your API thus far and think it's a pretty good start: Y'all put forth the laudable effort to actually create it, there's obviously a lot of forethought put into your proposal, and that certainly deserves respect! In fact, my team and I will probably be building off of what you've started in creating our proposal (which, again, I hope to have in a showable state before next week's meeting, and which I'm anticipating won't be the final form this API revision takes anyway.) Thanks, Stephen There are only two truly difficult problems in computer science: Naming things, cache invalidation, and off-by-one errors. On Thu, Apr 17, 2014 at 6:31 PM, Brandon Logan brandon.lo...@rackspace.com mailto:brandon.lo...@rackspace.com wrote: Stephen, Thanks for elaborating on this. I agreed and still do that our proposal's load balancer falls more in line with that glossary's term for listener and now can see the discrepancy with load balancer. Yes, in this case the term load balancer would have to be redefined, but that doesn't mean it is the wrong thing to do. I've always been on the side of the Load Balancing as a Service API using a root object called a load balancer. This just really makes sense to me and others, but obviously it doesn't for everyone. However, in our experience end users just understand the service better when the service takes in load balancer objects and returns load balancer objects. Also, since it has been tasked to defined a new API we felt that it was implied that some definitions were going to change, especially those that are subjective. There are definitely many definitions of a load balancer. Is a load balancer an appliance (virtual or physical) that load balances many protocols and ports and is it also one that load balances a single protocol on a single port? I would say that is definitely subjective. Obviously I, and others, feel that both of those are true. I would like to hear arguments as to why one of them is not true, though. Either way, we could have named that object a sqonkey and given a definition in that glossary. Now we can all agree that while that word is just an amazing word, its a terrible name to use in any context for this service. It seems to me that an API can define and also redefine subjective terms. I'm glad you don't find this as a deal breaker and are okay with redefining the term. I hope we all can come to agreement on an API and I hope it satisfies everyone's needs and ideas of a good API. Thanks, Brandon On 04/17/2014 07:03 PM, Stephen Balukoff wrote: Hi Brandon! Per the meeting this morning, I seem to recall you were looking to have me elaborate on why the term 'load balancer' as used in your API proposal is significantly different from the term 'load balancer' as used in the glossary at: https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary As promised, here's my elaboration on that: The glossary above states: An object that represent a logical load balancer that may have multiple resources such as Vips, Pools, Members, etc.Loadbalancer is a root object in the meaning described above. and references the diagram here: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion#Loadbalancer_instance_solution On that diagram, it's clear that VIPs, etc. are subordinate objects to a load balancer. What's more, attributes like 'protocol' and 'port' are not part of the load balancer object in that diagram (they're part of a 'VIP' in one proposed version, and part of a 'Listener' in the others). In your proposal, you state only one port and one protocol per load balancer, and then later (on page 9 under GET
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
On Apr 14, 2014, at 8:20 PM, Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote: Hello y'all! Over the last few months, I feel like we've seen a renewed vigor for participation in making the LBaaS project successful. After the (still unresolved) object model discussion started in January, based on feedback we were getting from Neutron core developers (mainly Mark McClain, from what I understand) this was followed up by a requirements discussion, a use cases discussion, and as of the last weekly IRC meeting, I think there are people in this group now working on proposals for API revision. We've coordinated this using various documents, and I think the ones that have carried the most weight are: * Object model revision summary as started by Eugene: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion (Feedback from core was the 'load balancer' object was an implementation detail. I think most people on this project don't think so, but it's clear more work was needed here.) * Requirements document as started by Jorge: https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements (Feedback was that requirements needed to be stated in the form of user or operator requirements, and not in the form of what a load balancer should do, per se.) * Samuel then created this google document to describe several use cases from the user's point of view: https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing * And to prioritize what features are needed, Jorge started this document to collect operator feature usage data (with current load balancer deployments, presumably outside of OpenStack, since Neutron LBaaS doesn't presently have many of these features): https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWcusp=sharing (Feedback on this is that everyone agrees the legacy API is really confusing, and that a clean break for the API for Juno is probably prudent, possibly preserving some backward compatibility with a versioned API. Further, it was clear we needed an example of what the new API should look like.) There are also these proposal documents for L7 and SSL functionality, presumably on hold until either the API draft being made is closer to reality, or until we come to an agreement on the required changes to the object model the proposals imply: https://wiki.openstack.org/wiki/Neutron/LBaaS/l7 https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL 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. We have been using the document when discussing our API proposal. The use cases had some surprising implications for our api proposal which we had to rethink. Particularly the L7 URL routing use case #7 As far as operator requirements I know our team is advocating a management API that is separate from the public api (Separate meaning regular users can reach its endpoint) but still apart of the CORE codebase. 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? Would it be prudent to make these decisions at the Atlanta summit or thereafter. 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). Our team, (Jorge's team) are investigating the API from the perspective of supporting Single Loadbalancer creation calls that is still compatible with the ability to create separate components such as vips pools ssl confs and lasteltly making a call that joins them to a loadbalancer. We wanted to iron out some of the gotcha's we've been encountering before we presented the proposals. Most recently we are looking at how allowing inplace object creation which Im calling literals vs the ability to create parent objects with the ids of previously created objects. I'll let brandon logan follow uo on this later on today. We are still in meetings right now about the API. |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
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
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.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 15, 2014 at 7:00 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto: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.netmailto: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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 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 Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Tuesday, April 15, 2014 at 7:00 AM To: openstack-dev@lists.openstack.org 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.netwrote: 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 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
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Sorry about that. It should be readable now. From: Eugene Nikanorov [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.commailto: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.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 15, 2014 at 7:00 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto: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.netmailto: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.orgmailto: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
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Eugene, Towards the bottom of that document it does mention content switching and how it would work with this. I know its a huge text document and hard to navigate but it is there. The point of the one pool on a load balancer is because other than content switching there aren't any other use cases for multiple pools. There's a question/answer about that. As we say in that document, it is not perfect but it is viable. If that is something most people do not like then another solution can be discussed. As for referencing objects within the same request body, it probably wasn't explained well but if you need to reference a pool that is being created within that POST body then referencing by the name attribute should be fine. That name should only be unique within that request body and references to that name should only be contained within the scope of the request body. After that, names don't have to be unique. Even if that wasn't a viable solution, I don't think a single call API should be quickly dismissed because of this. There are probably better elegant solutions we can come up with if everyone participated in a discussion about it. Again, I understand its a huge document and some things are probably not detailed well. If they are not just ask me to give more details. Thanks, Brandon Logan From: Eugene Nikanorov [enikano...@mirantis.com] Sent: Wednesday, April 16, 2014 4:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress 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. 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. 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 Thanks, Eugene. On Thu, Apr 17, 2014 at 12:59 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: Sorry about that. It should be readable now. From: Eugene Nikanorov [enikano...@mirantis.commailto: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.commailto: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.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 15, 2014 at 7:00 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto: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.netmailto:sbaluk
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
On Apr 16, 2014, at 4:31 PM, Eugene Nikanorov enikano...@mirantis.commailto: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.commailto:brandon.lo...@rackspace.com wrote: Sorry about that. It should be readable now. From: Eugene Nikanorov [enikano...@mirantis.commailto: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.commailto: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
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
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 wrote: Sorry about that. It should be readable now. -- *From:* Eugene Nikanorov [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 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 Reply-To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org Date: Tuesday, April 15, 2014 at 7:00 AM To: openstack-dev@lists.openstack.org 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 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
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
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.commailto:brandon.lo...@rackspace.com wrote: Sorry about that. It should be readable now. From: Eugene Nikanorov [enikano...@mirantis.commailto: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.commailto: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.commailto:enikano...@mirantis.com Reply-To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, April 15, 2014 at 7:00 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto: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.netmailto: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
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Hi all, In order to ease confusion I think I might create use case walk-throughs to show how the API would work. There's only been one week to work on this (minus other work) so I haven't had enough time to create them. I'll try to capture most of them in this form over the following week as I really think it will aid in understanding the document Brandon provided. Sometimes an illustration is easier to understand :). Anyways, just know that simplicity, flexibility and the ability to capture the majority of use cases was kept in mind when creating this proposal and I really think it will satisfy the requirements that everyone has put forth. See you all on IRC in a few hours! Cheers, --Jorge From: Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, April 16, 2014 9:17 PM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress 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
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.netwrote: 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Hi Stephen, Jorge, Myself, and our team having been collaborating drafting a revision of the API. We should be able to put it up on the wiki most likely tomorrow but possibly Thursday. We definitely prefer to get it out tomorrow, though. It is definitely something we'd like everyone to pick apart and come up with how it may break use cases and also how it may break the rule of it being too specific. We're definitely keeping all of that in mind but different experienced sets of eyes will always come up with some flaws and things we didn't think about. Thanks, Brandon Logan From: Eugene Nikanorov [enikano...@mirantis.com] Sent: Tuesday, April 15, 2014 7:00 AM To: OpenStack Development Mailing List (not for usage questions) 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.netmailto: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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Requirements and API revision progress
Hello y'all! Over the last few months, I feel like we've seen a renewed vigor for participation in making the LBaaS project successful. After the (still unresolved) object model discussion started in January, based on feedback we were getting from Neutron core developers (mainly Mark McClain, from what I understand) this was followed up by a requirements discussion, a use cases discussion, and as of the last weekly IRC meeting, I think there are people in this group now working on proposals for API revision. We've coordinated this using various documents, and I think the ones that have carried the most weight are: * Object model revision summary as started by Eugene: https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion (Feedback from core was the 'load balancer' object was an implementation detail. I think most people on this project don't think so, but it's clear more work was needed here.) * Requirements document as started by Jorge: https://wiki.openstack.org/wiki/Neutron/LBaaS/requirements (Feedback was that requirements needed to be stated in the form of user or operator requirements, and not in the form of what a load balancer should do, per se.) * Samuel then created this google document to describe several use cases from the user's point of view: https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?usp=sharing * And to prioritize what features are needed, Jorge started this document to collect operator feature usage data (with current load balancer deployments, presumably outside of OpenStack, since Neutron LBaaS doesn't presently have many of these features): https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWcusp=sharing (Feedback on this is that everyone agrees the legacy API is really confusing, and that a clean break for the API for Juno is probably prudent, possibly preserving some backward compatibility with a versioned API. Further, it was clear we needed an example of what the new API should look like.) There are also these proposal documents for L7 and SSL functionality, presumably on hold until either the API draft being made is closer to reality, or until we come to an agreement on the required changes to the object model the proposals imply: https://wiki.openstack.org/wiki/Neutron/LBaaS/l7 https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL 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. 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? 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). 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. :/ ) Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
