<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><div></div></div><div>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 "<span style="white-space:pre-wrap">to prepare API for SSL and L7" directive for my team yourself!</span></div>

<div><br></div><div>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.</div>

<div><br></div><div>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.)</div>
</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div><br></div><div>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. </div>
</div></div></div></blockquote><div>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.</div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">

<div><br></div><div>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?</div></div></div></div></blockquote><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>Right, so *if* we decide to go with my proposal, we need to first decide which parts we're actually going to go with--</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> 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, </div>
</div></div></div></blockquote><div>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?</div><div>The discussion could be on how to do it, then.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>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.)</div>

<div><br></div><div>Why embark on this process at all if we don't have any real idea of what the end-goal looks like?</div></div></div></div></blockquote><div>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.</div>
<div><br></div><div>So speaking about 'holistic view', please tell, how L7 and SSL are related, does one depend on another or affect another?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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!</div>
</div></div></div></blockquote><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>My point is: Unless you have already considered how to do SSL and L7, then any object model change proposal is essentially pointless. </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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?</div></div></div>
</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div><br></div><div>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.</div>
</div></div></div></blockquote><div>...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div>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.</div>
<div class="">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">

<div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">

<div>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?<br></div>



</div></div></div></blockquote></div><div>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.</div>

</div></div></div></blockquote><div><br></div></div><div>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.</div>
</div></div></div></blockquote><div><br></div><div>What exactly made you think that we are blindly suggesting drastic API and object model change?</div><div>Is that because L7 & SSL proposals were made long before you, folks from HP and Rackspace has jumped in?</div>
<div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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).<br>

<br>Would it help if I called it an "efkalb" in my proposal instead?</div></div></div></div></blockquote><div>No, it would not help. The root cause is 'virtualized appliance' vs 'virtual network function' question.</div>
<div>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.</div>
<div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>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.</div>
</div></div></div></blockquote><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>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? </div>
</div></div></div></blockquote><div>It's not hard at all. Explaining obvious things and getting consensus is hard.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>My proposal is a <i>design discussion</i>. </div></div></div></div></blockquote><div>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.</div>
<div>Exact design of L7 rules is not required to know how to move 'root object' role from Pool to Vip.</div><div>Exact design of SSL is not required to know how to allow multiple tcp endpoints.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>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.</div>
</div></div></div></blockquote><div>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?! </div>
<div>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? </div><div> </div><div><br></div><div>
Eugene.</div></div></div></div>