<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>
<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><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-family:Calibri,sans-serif;font-size:14px">to design for what we know we need</span><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">", 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><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><br></div><div>Thanks,</div><div>Eugene.</div></div></div></div>