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.miramon...@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.miramon...@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@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev