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