Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140428/37ca40ac/attachment.html>