Open Stack

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 <SamuelB at radware.com>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:mestery at noironetworks.com]
> 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 <sbalukoff at bluebox.net>
> 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
> > <german.eichberger at 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:SamuelB at 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-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:mestery at 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
> >> <enikanorov at 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 at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Stephen Balukoff
> > Blue Box Group, LLC
> > (800)613-4305 x807
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140429/0e71e4e8/attachment.html>