Open Stack

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
>