Open Stack

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?

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.

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