Open Stack

Vijay,

Comments in-line, hope I can clear some of this up for you :)

-Trevor

On Thu, 2014-05-01 at 13:16 +0000, Vijay Venkatachalam wrote:
> I am expecting to be more active on community on the LBaaS front. 
> 
> May be reviewing and picking-up a few items to  work as well.
> 
> I had a look at the proposal. Seeing Single & Multi-Call approach for each workflow 
> makes it easy to understand. 
> 
> Thanks for the clear documentation, it is welcoming to review :-). I was not allowed to comment on WorkFlow doc, can you enable comments?
> 
> The single-call approach essentially creates the global pool/VIP. Once VIP/Pool is created using single call, are they reusable in multi-call?
> For example: Can a pool created for HTTP endpoint/loadbalancer be used in HTTPS endpoint LB where termination occurs as well?

From what I remember discussing with my team (being a developer under
Jorge's umbrella) There is a 1-M relationship between load balancer and
pool.  Also, the protocol is specified on the Load Balancer, not the
pool, meaning you could expose TCP traffic via one Load Balancer to a
pool, and HTTP traffic via another Load Balancer to that same pool.
This is easily modified such 

> 
> Also, would it be useful to include PUT as a single call? I see PUT only for POOL not for LB.
> A user who started with single-call  POST, might like to continue to use the same approach for PUT/update as well.

On the fifth page of the document found here:
https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWyXe-zo/edit
There is a PUT detailed for a Load Balancer.  There should be support
for PUT on any parent object assuming the fields one would update are
not read-only.

> 
> Thanks,
> Vijay V.
> 
> -----Original Message-----
> From: Jorge Miramontes [mailto:jorge.miramontes at RACKSPACE.COM] 
> Sent: Thursday, May 1, 2014 3:57 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process
> 
> Oops! Everywhere I said Samuel I meant Stephen. Sorry you both have SB as you initials so I got confused. :)
> 
> Cheers,
> --Jorge
> 
> 
> 
> 
> On 4/30/14 5:17 PM, "Jorge Miramontes" <jorge.miramontes at RACKSPACE.COM>
> wrote:
> 
> >Hey everyone,
> >
> >I agree that we need to be preparing for the summit. Using Google docs 
> >mixed with Openstack wiki works for me right now. I need to become more 
> >familiar the gerrit process and I agree with Samuel that it is not 
> >conducive to "large" design discussions. That being said I'd like to 
> >add my thoughts on how I think we can most effectively get stuff done.
> >
> >As everyone knows there are many new players from across the industry 
> >that have an interest in Neutron LBaaS. Companies I currently see 
> >involved/interested are Mirantis, Blue Box Group, HP, PNNL, Citrix, 
> >eBay/Paypal and Rackspace. We also have individuals involved as well. I 
> >echo Kyle's sentiment on the passion everyone is bringing to the project!
> >Coming into this project a few months ago I saw that a few things 
> >needed to be done. Most notably, I realized that gathering everyone's 
> >expectations on what they wanted Neutron LBaaS to be was going to be 
> >crucial. Hence, I created the requirements document. Written 
> >requirements are important within a single organization. They are even 
> >more important when multiple organizations are working together because 
> >everyone is spread out across the world and every organization has a 
> >different development process. Again, my goal with the requirements 
> >document is to make sure that everyone's voice in the community is 
> >taken into consideration. The benefit I've seen from this document is 
> >that we ask "Why?" to each other, iterate on the document and in the 
> >end have a clear understanding of everyone's motives. We also learn 
> >from each other by doing this which is one of the great benefits of open source.
> >
> >Now that we have a set of requirements the next question to ask is, 
> >"How doe we prioritize requirements so that we can start designing and 
> >implementing them"? If this project were a completely new piece of 
> >software I would argue that we iterate on individual features based on 
> >anecdotal information. In essence I would argue an agile approach.
> >However, most of the companies involved have been operating LBaaS for a 
> >while now. Rackspace, for example, has been operating LBaaS for the 
> >better part of 4 years. We have a clear understanding of what features 
> >our customers want and how to operate at scale. I believe other 
> >operators of LBaaS have the same understanding of their customers and 
> >their operational needs. I guess my main point is that, collectively, 
> >we have data to back up which requirements we should be working on. 
> >That doesn't mean we preclude requirements based on anecdotal 
> >information (i.e. "Our customers are saying they want new shiny feature 
> >X"). At the end of the day I want to prioritize the community's 
> >requirements based on factual data and anecdotal information.
> >
> >Assuming requirements are prioritized (which as of today we have a 
> >pretty good idea of these priorities) the next step is to design before 
> >laying down any actual code. I agree with Samuel that pushing the cart 
> >before the horse is a bad idea in this case (and it usually is the case 
> >in software development), especially since we have a pretty clear idea 
> >on what we need to be designing for. I understand that the current code 
> >base has been worked on by many individuals and the work done thus far 
> >is the reason why so many new faces are getting involved. However, we 
> >now have a completely updated set of requirements that the community 
> >has put together and trying to fit the requirements to existing code 
> >may or may not work. In my experience, I would argue that 99% of the 
> >time duct-taping existing code to fit in new requirements results in 
> >buggy software. That being said, I usually don't like to rebuild a 
> >project from scratch. If I can I try to refactor as much as possible 
> >first. However, in this case we have a particular set of requirements 
> >that changes the game. Particularly, operator requirements have not been given the attention they deserve.
> >
> >I think of Openstack as being cloud software that is meant to operate 
> >at scale and have the necessary operator tools to do so. Otherwise, why 
> >do we have so many companies interested in Openstack if you can't 
> >operate a cloud that scales? In the case of LBaaS, user/feature 
> >requirements and operator requirements are not necessarily mutually 
> >exclusive. How you design the system in regards to one set of 
> >requirements affects the design of the system in regards to the other 
> >set of requirements. SSL termination, for example, affects the ability 
> >to scale since it is CPU intensive. As an operator, I need to know how 
> >to provision load balancer instances efficiently so that I'm not having 
> >to order new hardware more than I have to. With this in mind, I am 
> >assuming that most of us are vendor-agnostic and want to cooperate in 
> >developing an open source driver while letting vendors create their own 
> >drivers. If this is not the case then perhaps a lot of the debates we 
> >have been having are moot since we can separate efforts depending on 
> >what driver we want to work on. The only item of Neutron LBaaS that we 
> >need to have consensus on then is the API (web app, database, messaging 
> >system, etc.). Keep in mind that the API implies what feature/user 
> >requirements are satisfied, but no so much for operator requirements. I 
> >think this is one reason why we have been working on API proposals. 
> >Samuel, thank you for the time you spent on your proposal as we know how much time and effort it takes.
> >
> >Because several of us have been spending large amounts of time on API 
> >proposals, and because we can safely assume that most operational 
> >requirements are abstracted into the driver layer I say we continue the 
> >conversation around the different proposals since this is the area we 
> >definitely need consensus on. So far there are three 
> >proposals--Stephen's, Rackspace's and Eugene's. To date, we honestly 
> >haven't had an actual discussion on the pros and cons of each proposal. 
> >To give structure to this we here at Rackspace have been going to great 
> >lengths to make sure we have enough tangible documentation in order to 
> >clearly convey our thoughts. We also went to great lengths to satisfy 
> >the user/feature requirements in our API. Here is what we have done:
> >
> >- An API specification located here ==> 
> >https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bT
> >mWy
> >X
> >e-zo/edit
> >- Single API call workflows & multiple API call workflows of each of 
> >the use cases (#1 through #9 for now) from 
> >https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-
> >mXu
> >S
> >INis/edit#heading=h.48fieovwttzg. Our workflows are located here ==>
> >https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0
> >- A lightweight proof of concept that is in the works so that people 
> >that need to actually send requests to an API to believe in it can do 
> >so. We will send an update in a few days when this POC is complete.
> >
> >In order to fairly compare proposals I think it would be nice if each 
> >proposal give workflows on how their API will operate. This is isn't 
> >necessary but I think it will definitely give structure in any 
> >discussions we have when comparing. If others have thoughts on how to 
> >compare the proposals on equal footing then by all means speak up.
> >
> >Once we come to a consensus on the API then we can figure out how to 
> >make iterative changes in order to get the API to the consensus state. 
> >That is a separate conversation in my mind. First we need to agree on a 
> >spec without the confines of looking at current implementation.
> >
> >
> >Cheers,
> >--Jorge
> >
> >
> >P.S. Sorry for the delay in responding to the ML. Just reading them 
> >takes several hours.
> >
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev