<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>
<div>
<div>As usual, comments are inline.</div>
<div><br>
</div>
<div>
<div>Cheers,</div>
<div style="font-family: Calibri, sans-serif; "><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">--Jorge</font></font></div>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, May 1, 2014 3:10 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">Hi,<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, May 1, 2014 at 10:46 PM, Jorge Miramontes <span dir="ltr">
<<a href="mailto:jorge.miramontes@rackspace.com" target="_blank">jorge.miramontes@rackspace.com</a>></span> wrote:<br>
<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 style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div>Hey Eugene,</div>
<div><br>
</div>
<div>I think there is a misunderstanding on what iterative development means to you and me and I want to make sure we are on the same page. First of all, I'll try not to use the term "duct-taping" even though it's a widely used term in the industry.
</div>
</div>
</div>
</div>
</blockquote>
<div>I'm not against the term itself. </div>
<div>It was applied several times to existing code base, apparently without ANY real code analysis.</div>
<div>That's especially clearly seen because all API proposals so far are focusing on managing the same set of lb primitives.</div>
<div>Yes, the proposals introduce some new primitives; yes some attributes and relationships differ from what is in the code. </div>
<div>But nothing was proposed so far that would require to completely throw away existing code, not a single requirement.</div>
<div><br>
</div>
<div>I understand that writing something from scratch can be more convenient for developers than studying existing code, but that's something we all have to do when working on opensource project.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>To be perfectly clear we are not advocating "starting from scratch". If it has come out that way then let me be the first to correct that on behalf of my team. In reality, defining a brand new API specification is irrelevant to implementation. I like to
see defining a spec as similar to defining an RFC. The reason why I don't even want to think about implementation is that it does not allow discussion to be open-minded. I agree that a particular API proposal might be easier to mold existing code to than another.
However, this goes against the mentality of comparing on equal footing. You, for example, seem biased toward Stephen's proposal because you understand the current code base the best (since you wrote the majority of it) and see his proposal as most inline with
said code. However, I ask that you try not to let current implementation cloud your judgement. If Stephen's proposal is what the community agrees upon then great! All I ask is that we compare fairly and without implementation in mind since we are defining
what we want, not what we currently have in place. Once an API specification is agreed upon, then and only then, should we figure out how to mold the existing implementation towards the state the spec defines. Does that make sense?</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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 style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div>My main concern is that implementing code on top of the current codebase to meet the smorgasbord of new requirements without thinking about overall design (since we know we will eventually want all the requirements satisfied at some point per your words)
</div>
</div>
</div>
</div>
</blockquote>
<div>Overall design was thought out long before we started having all these discussions. </div>
<div>And things are not quick in neutron project, that's regardless of amount of dev resources lbaas subteam may have.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>While overall design may have been thought out long ago it doesn't mean that the discussion should be closed. By saying this, you are implying that newcomers are not welcome those discussions. At least, that is how your statement rubs off on me. I'll give
you the benefit of the doubt to correct my understanding of that.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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 style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div>is that some requirement implemented 6 months from now may change code architecture. Since we know we want to meet all requirements eventually, its makes logical sense to design for what we know we need and then figure out how to iteratively implement
code over time. </div>
</div>
</div>
</div>
</blockquote>
<div>That was initially done on Icehouse summit, and we just had to reiterate the discussion for new subteam members who has joined recently.</div>
<div>I agree that "<span style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">to design for what we know we need</span><span style="color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">", but the primary option
should be to continue existing work and analyse it to find gaps, that what Samuel and me were focusing on. Stephen's proposal also goes along this idea because everything in his doc can be implemented gradually starting from existing code.</span></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 style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div>That being said, if it makes sense to use existing code first then fine. In fact, I am a fan of trying manipulate as little code as possible unless we absolutely have to. I just want to be a smart developer and design knowing I will eventually have to
implement something. Not keeping things in mind can be dangerous.</div>
</div>
</div>
</div>
</blockquote>
<div>I fully agree and that's well understood.</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 style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div>In short, I want to avoid having to perform multiple code refactors if possible and design upfront with the list of requirements the community has spent time fleshing out.</div>
<div><br>
</div>
<div>Also, it seems like you have some implicit developer requirements that I'd like written somewhere. This may ease confusion as well. For example, you stated "Consistency is important". A clear definition in the form of a developer requirement would be nice
so that the community understands your expectations.</div>
</div>
</div>
</div>
</blockquote>
<div>It might be a bit difficult to formalize. So you know, we're not the only ones who will make decisions on the implementation.</div>
<div>There is a core team, who mostly out of lbaas discussions right now (and that fact will not change), who have their own views on how neutron API should look like, what is allowed and what is not. To get a sense of it, one really needs to contribute to
neutron: push the code through 10-20-50 review iterations, see what other developers are concerned about.</div>
<div>Obviously we can't get everyone to our discussions, but other core dev may (or may not, i don't know for sure) just -1 your implementation because you to /object1/id/object2/id/object3/id instead of flat rest API that neutron has, or something like that. </div>
<div>Then you'll probably spend another month or two trying to discuss these issues again with other group of folks.</div>
<div>We don't have rigid guidelines on how the code should be written; understanding of that comes with experience and with discussions on gerrit.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>The fact that there are no core developers on Neutron LBaaS is concerning to say the least even though there are a large number of people/companies now involved. I have other thoughts on this but will leave that for another day.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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 style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>
<div>Lastly, in relation to operator requirements I didn't see you comment on whether you are fan of working on an open-source driver together. Just so you know, operator requirements are very important for us and I honestly don't see how we can use any current
driver without major modifications. This leads me to want to create a new driver with operator requirements being central to the design.</div>
</div>
</div>
</div>
</blockquote>
<div>The driver itself, IMO, is the most flexible part of the system. If you think it needs to be improved or even rewritten (once it does what user asks it to do via API) - I'd be glad to discuss that. I think rm_work (is that Adam Harwell?) was going to start
a thread on this in ML.</div>
<div><br>
</div>
<div>Btw, am my understanding is correct that you (as cloud operator) are mostly interested in haproxy as a backend?</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>Correct. We are mostly interested in using a pure open-source backend. HAProxy is definitely where we will be starting.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Thanks,</div>
<div>Eugene.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>