Open Stack

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.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-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: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140429/2e881a2c/attachment-0001.html>