Per Samuel's request, I have set my API proposal document to be edit-able by all.
Also, my work priorities have changed somewhat in preparation for the summit in two weeks, so I may not be able to add more use cases prior to the summit. On Tue, Apr 29, 2014 at 3:55 AM, Samuel Bercovici <[email protected]>wrote: > Hi, > > I think it is a good idea to have the use cases in a different document > that API proposals (Stephen's, included) > Once we declare the uses cases done for Juno, I will move it to the BP > repository. > I would also like to see operator's use cases flushed out in the document. > > Stephen, could you please open the document also for editing? > > Regards, > -Sam. > > > > > -----Original Message----- > From: Kyle Mestery [mailto:[email protected]] > Sent: Tuesday, April 29, 2014 5:27 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal > > On Mon, Apr 28, 2014 at 6:23 PM, Stephen Balukoff <[email protected]> > wrote: > > Hi guys, > > > > Sorry for all the drama on the list lately. > > > Not a problem. Like I said, the passion from all sides is great, and I'm > especially happy to see all the operators engaging with Neutron for LBaaS. > > > Kyle: I appreciate the sentiment. I'd also be happy to open up my API > > doc for general editing by people on the internet (and not just > > comments) if you think that would help. > > > My main reason for asking this was in case the gerrit bar was too high for > new people to Neutron and LBaaS in particular. I want to make sure we > capture everyone's ideas and allow everyone a chance to comment. > The gerrit BP process does this nicely, but I just want to ensure it's not > too high of a bar for people new to the entire process. > > > For us new-comers to the OpenStack project environment, what do people > > usually use for discussing potential design changes (and especially > > large design changes)? (From my perspective, Blue prints seem mostly > > useful as collections of links to other documents, without having an > > obvious way to discuss things in the blueprint directly. Gerrit seems > > like it's mostly "github workflow" with CI baked in-- ie. useful for > > specific smaller code changes, but not as much for design-level > > discussions. I suppose etherpads might duplicate much of the > > functionality we're currently using google docs to accomplish (though > > I don't think etherpads have the ability to do spreadsheets, from what I > can tell). > > > I think it's fine to use the gdoc for now, with the idea being we will > then converge on work items formed into multiple BPs out of the gdoc. > So perhaps it does make sense to use your document as the communal > starting point for this. But I'm open to what others may say as well. > > > As far as the meetings go: It might help if you could share with us > > what you hope to accomplish prior to the summit, and what kinds of > > things you'd like us to be prepared to discuss at the summit. (Is > > there an LBaaS meeting of some kind scheduled there yet?) > > > I've given LBaaS 2 40 minute sessions. What I'd like us to do is come to > come to a consensus on what needs discussing in person vs. what everyone is > agreeing on and we don't need to discuss in those sessions. If we need time > to discuss the object model and API in Atlanta, that's fine too. > > > For my part, I plan on concentrating on filling out more use cases and > > then returning to the software load balancer virtual appliance porting > > project that's been on the back-burner for way too long for me. > > > Perfect! How about if we try to close the use case gap for this week's > LBaaS meeting. Then, next week we can at least make a stab at the object > model and API which satisfies as many use cases as we come up with. > > > Samuel and German: I've gone ahead and added around 20 new use cases > > to the google doc you linked. More will be on the way, but I'm happy > > to add these to gerrit myself if you'd prefer, so long as I can see > > how you're doing this for the first use cases and can follow your > > template. Let me know if you'd like me to change what I've been doing > > here, eh! Note also that so far these are only "user" use cases; It > > doesn't look like admin/operator use cases have been filled out at all > yet. > > > Getting the admin/operator use cases in there would be good as well > Stephen. > > Thanks, > Kyle > > > Thanks, > > Stephen > > > > > > > > > > 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-w2FScERQXQR > >> 1-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 > > > > > > > > > > -- > > Stephen Balukoff > > Blue Box Group, LLC > > (800)613-4305 x807 > > > > _______________________________________________ > > 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 > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
