Hi Sam, Evgeny, I've reviewed https://review.openstack.org/#/c/74031 with my comments. I am not sure if there is a request with code newer than this link - please do let me know if that is the case.
Thanks, Regards, Vijay On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German < [email protected]> wrote: > Sam, > > The use cases where pretty complete the last time I checked so let's move > them to gerrit so we can all vote. > > Echoing Kyle I would love to see us focusing on getting things ready for > the summit. > > German > > -----Original Message----- > From: Samuel Bercovici [mailto:[email protected]] > Sent: Monday, April 28, 2014 11:44 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal > > Hi, > > I was just working to push the use cases into the new format .rst but I > agree that using google doc would be more intuitive. > Let me know what you prefer to do with the use cases document: > 1. leave it at google docs at - > https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1 > 2. Move it to the new format under - > http://git.openstack.org/cgit/openstack/neutron-specs, I have already > files a blue print > https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and can > complete the .rst process by tomorrow. > > Regards, > -Sam. > > > > > > > -----Original Message----- > From: Kyle Mestery [mailto:[email protected]] > Sent: Monday, April 28, 2014 4:33 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal > > Folks, sorry for the top post here, but I wanted to make sure to gather > people's attention in this thread. > > I'm very happy to see all the passion around LBaaS in Neutron for this > cycle. As I've told a few people, seeing all the interest from operators > and providers is fantastic, as it gives us valuable input from that side of > things before we embark on designing and coding. > I've also attended the last few LBaaS IRC meetings, and I've been catching > up on the LBaaS documents and emails. There is a lot of great work and > passion by many people. However, the downside of what I've seen is that > there is a logjam around progress here. Given we're two weeks out from the > Summit, I'm going to start running the LBaaS meetings with Eugene to try > and help provide some focus there. > Hopefully we can use this week and next week's meetings to drive to a > consistent Summit agenda and lay the groundwork for LBaaS in Juno and > beyond. > > Also, while our new neutron-specs BP repository has been great so far for > developers, based on feedback from operators, it may not be ideal for those > who are not used to contributing using gerrit. I don't want to lose the > voice of those people, so I'm pondering what to do. This is really > affecting the LBaaS discussion at the moment. I'm thinking that we should > ideally try to use Google Docs for these initial discussions and then move > the result of that into a BP on neutron-specs. What do people think of that? > > If we go down this path, we need to decide on a single Google Doc for > people to collaborate on. I don't want to put Stephen on the spot, but his > document may be a good starting point. > > I'd like to hear what others think on this plan as well. > > Thanks, > Kyle > > > On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov <[email protected]> > wrote: > > Hi, > > > >> > >> You knew from the action items that came out of the IRC meeting of > >> April > >> 17 that my team would be working on an API revision proposal. You > >> also knew that this proposal was to be accompanied by an object model > >> diagram and glossary, in order to clear up confusion. You were in > >> that meeting, you saw the action items being created. Heck, you even > >> added the "to prepare API for SSL and L7" directive for my team > yourself! > >> > >> The implied but not stated assumption about this work was that it > >> would be fairly evaluated once done, and that we would be given a short > window (ie. > >> about a week) in which to fully prepare and state our proposal. > >> > >> Your actions, though, were apparently to produce your own version of > >> the same in blueprint form without notifying anyone in the group that > >> you were going to be doing this, let alone my team. How could you > >> have given my API proposal a fair shake prior to publishing your > >> blueprint, if both came out on the same day? (In fact, I'm lead to > >> believe that you and other Neutron LBaaS developers hadn't even > >> looked at my proposal before the meeting on 4/24, where y'all started > >> determining product direction, apparently by > >> edict.) > >> > >> > >> Therefore, looking honestly at your actions on this and trying to > >> give you the benefit of the doubt, I still must assume that you never > >> intended to seriously consider our proposal. > > > > That's strange to hear because the spec on review is a part of what is > > proposed in the document made by you and your team. > > Once again I'm not sure what this heated discussion is all about. The > > doc does good job and we will continue discussing it, while a part of > > it (spec about VIPs/Listeners/Pools) is on review where we, as lbaas > > subteam, actually can finalize a part of it. > > > >> > >> Do you now understand why I find this offensive? Can you also > >> understand how others, seeing how this was handled, might now be > >> reluctant to participate? > > > > People may find different things to be offensive. I can also say much > > on this, but would not like not continue the conversation in this > direction. > > > > > >> Right, so *if* we decide to go with my proposal, we need to first > >> decide which parts we're actually going to go with-- > >> > >> I don't expect my proposal to be complete or perfect by any means, > >> and we need to have honest discussion of this first. Then, once we've > >> more-or-less come to a consensus on this overall direction, > > > > I'm not sure i understand what you mean by 'overall direction'. Was > > there ever an idea of not supporting HA, or L7, or SSL or to not > > satisfy other requirements? > > The discussion could be on how to do it, then. > > > >> it makes sense to think about how to split up the work into > >> digestible, parallelize-able chunks that can be tackled by the > >> various interested parties working on this project. (My team > >> actually wanted to propose a road map and attach it to the proposal, > >> but there simply wasn't time if we wanted to get the API out before > >> the next IRC meeting in enough time for people to have had a chance > >> to look at it.) > >> > >> Why embark on this process at all if we don't have any real idea of > >> what the end-goal looks like? > > > > I hope this will not look offensive if I say that the 'end goal' was > > discussed at Grizzly, Havana and Icehouse summit and even before. > > While not every requirement was discussed on the summits, there was > > quite clear understanding of the dependencies between features. And I > > don't mean that 'roadmap is fixed' or anything like that, I'm just > > saying that thinking about the end-goal is not something we've started > to do 1.5 months ago. > > > > So speaking about 'holistic view', please tell, how L7 and SSL are > > related, does one depend on another or affect another? > > > >> > >> Right-- so paraphrasing what I think you're saying: "Let's consider > >> how we're going to tackle the SSL and L7 problems at a later date, > >> once we've fixed the object model to be compatible with how we're > >> going to tackle SSL and L7." This implies you've already considered > >> how to tackle SSL and L7 in making your object model change proposal! > > > > That was mostly about L7, but for sure subteam has considered and > > designed L7, and I also assume you've seen those design docs made by > > Sam: on your diagrams I see the same objects and relationship as in > Samuel's doc. > > > >> My point is: Unless you have already considered how to do SSL and L7, > >> then any object model change proposal is essentially pointless. > >> > >> Why make these changes unless we already know we're going to do SSL > >> and L7 in some way that is compatible with the proposed changes? > >> > >> > >> Evaluating these things *necessarily* must happen at the same time (ie. > >> holistically) or the object model proposal is pointless and unjustified. > >> Actually implementing the design will happen first with the core > >> object model changes, and then the SSL and L7 features. > > > > ... > >> > >> But I think I've already made my point that not considering things > >> like SSL and L7 in any proposal means there's no clear indication > >> that core object model changes will be compatible with what needs to > >> happen for SSL and L7. > >> > >>>> > >>>> Also, please understand that "multiple pools" is L7! Can anyone > >>>> name a use case where multiple back-end pools are used on a single > >>>> listener that doesn't involve some L7 logic in there somewhere? > >>> > >>> Right, it is L7. And I'm not trying to add L7, I'm just getting rid > >>> of 'Pool as the root object' that has prevented L7 from being > >>> implemented, that is in scope of my proposal. Actually adding L7 is > out of scope of it. > >> > >> > >> Ok, so I'm hearing you say that L7 is out of scope, but changes which > >> enable the possibility of L7 are not. I would say that the latter > >> cannot be done without considering how former is likely to be done. > >> So while actually implementing L7 can be done separately, evaluating > >> the proposed object model / API design changes cannot be. > > > > > > What exactly made you think that we are blindly suggesting drastic API > > and object model change? > > Is that because L7 & SSL proposals were made long before you, folks > > from HP and Rackspace has jumped in? > > Then I can only regret that that I didn't conduct a line of lectures > > explaining the current state of the code as well as the state of > > publicly available proposals. > > > >> Ok, that still seems to me like you're taking that stance because > >> people in Neutron core see the word "load balancer" and assume it's > >> an implementation detail (without actually defining what an > >> implementation detail is, nor apparently looking at the glossary we > >> made largely to address the confusion around this term). > >> > >> Would it help if I called it an "efkalb" in my proposal instead? > > > > No, it would not help. The root cause is 'virtualized appliance' vs > > 'virtual network function' question. > > Putting this in more practical angle: is it necessary from user > > standpoint to be able to create more than one L2 endpoint (port) for > > single load balancing configuration? I think that's the defining > question. > > > >> > >> Also for clarification: I'm not trying to knock those who do code > >> early (producing POCs and whatnot). Sometimes the only way to come up > >> with specific requirements is to see what can be done by trying out > >> different ways to solve a problem. But it seems unrealistic to me to > >> expect initial exploratory efforts in this regard to end up in final > product. > > > > It's just now they suddenly became exploratory. Because someone has > > introduced whole set of new requirements that didn't exist at the > > point when the design and the code was written. While it's fine to > > adopt and reevaluate them with new requirements, it's not fine to say > > folks didn't have their requirements. > > > >> Whenever I see this done, where assumptions about how the pieces fit > >> together are not re-evaluated once exploratory POCs have yielded more > >> knowledge or where said POCs end up becoming the final product, I see > >> significant design flaws that get baked into final products. Why do > >> y'all think it's been so hard to get "VIP" and "Listener" and "Pool" > >> separated into separate entities? > > > > It's not hard at all. Explaining obvious things and getting consensus > > is hard. > > > >> My proposal is a design discussion. > > > > My opinion is that design discussion alone can be split by features. > > My opinion is that while there are some dependencies between features, > > they are not such that design discussion can't be split. > > Exact design of L7 rules is not required to know how to move 'root > object' > > role from Pool to Vip. > > Exact design of SSL is not required to know how to allow multiple tcp > > endpoints. > > > >> Look, I agree that splitting out VIP, Listener, and Pool to be their > >> own objects, and moving the "root" of the object tree to the VIP is > >> probably the right thing to do. But there are valuable contributors > >> in this discussion who are still not on-board with this idea. So why > >> is this fundamental design discussion being closed early? That was the > point of my comment. > > > > So the discussion has been held up for whole release cycle, with two > > last months this particular proposal being out on the wiki and > > discussed on the meetings. And then again people say about 'duct > > taping' current API and 'convenience of legacy developers'. How valuable > is that?! > > Especially given the fact the proposal on gerrit describes the part > > which actually had the consensus on the meetings, I might also ask - > > are people reading other's specs at all? > > > > > > Eugene. > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
