Open Stack

Also, a section for the API specification for the newly created SSL
extensions needs to be added to
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL.

Regards,
Vijay


On Tue, Apr 29, 2014 at 1:55 PM, Vijay B <os.vbvs at 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.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/3c084333/attachment.html>