Hi Carlos, It looks like only the gerrit review has been marked abandoned because of a week of inactivity.
Regards, Vijay On Tue, Apr 29, 2014 at 4:51 PM, Carlos Garza <carlos.ga...@rackspace.com>wrote: > This blueprint was marked abandoned. > > On Apr 29, 2014, at 3:55 PM, Vijay B <os.v...@gmail.com> > wrote: > > 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 < > german.eichber...@hp.com> 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:samu...@radware.com] >> 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:mest...@noironetworks.com] >> 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 < >> enikano...@mirantis.com> 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 >> > 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 >> > > _______________________________________________ > 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