Open Stack

I have seen many use casses added lately with me also adding additional 2 for L7 and will probably add a few more tomorrow for SSL termination

-----Original Message-----
From: Eichberger, German [mailto:german.eichberger at hp.com] 
Sent: Tuesday, April 29, 2014 12:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

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