<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</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>With regard to the last paragraph/sentence about a new driver, I am writing a lengthy analysis of that specific topic currently — hopefully we will be able to start an in-depth discussion on that later today.</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>--Adam</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>Jorge Miramontes <<a href="mailto:jorge.miramontes@RACKSPACE.COM">jorge.miramontes@RACKSPACE.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 1:46 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>
<div>
<div 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>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. 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) 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. 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. 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><br>
</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><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 8:12 AM<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 Jorge,
<div><br>
</div>
<div>A couple of inline comments:</div>
<div class="gmail_extra">
<div class="gmail_quote">
<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">
<br>
Now that we have a set of requirements the next question to ask is, "How<br>
doe we prioritize requirements so that we can start designing and<br>
implementing them"? </blockquote>
<div>Prioritization basically means that we want to support everything and only choose what is</div>
<div>more important right now and what is less important and can be implemented later.</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">
Assuming requirements are prioritized (which as of today we have a pretty<br>
good idea of these priorities) the next step is to design before laying<br>
down any actual code.</blockquote>
<div>That's true. I'd only would like to notice that there were actually a road map and requirements</div>
<div>with design before the code was written, that's both for the features that are already implemented,</div>
<div>and those which now are hanging in limbo.</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">
I agree with Samuel that pushing the cart before the<br>
horse is a bad idea in this case (and it usually is the case in software<br>
development), especially since we have a pretty clear idea on what we need<br>
to be designing for. I understand that the current code base has been<br>
worked on by many individuals and the work done thus far is the reason why<br>
so many new faces are getting involved. However, we now have a completely<br>
updated set of requirements that the community has put together and trying<br>
to fit the requirements to existing code may or may not work. </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">
In my experience, I would argue that 99% of the time duct-taping existing code<br>
</blockquote>
<div>I really don't like the term "duct-taping" here.</div>
<div>Here's the problem: you'll never will be able to implement everything at once, you have to do it incrementally.</div>
<div>That's how ecosystem works. </div>
<div>Each step can be then considered as 'duct-taping' because each state you're getting to</div>
<div>is not accounting for everything what was planned. </div>
<div>And for sure, there will be design mistakes that need to be fixed.</div>
<div>In the end there will be another cloud provider with another set of requirements...</div>
<div><br>
</div>
<div>So in order to deal with that in a productive way there are a few guidelines:</div>
<div>1) follow the style of ecosystem. Consistency is important. Keeping the style helps both developers, reviewers and users of the product.</div>
<div>2) Preserve backward compatibility whenever possible.</div>
<div>That's a very important point which however can be 'relaxed' if existing code base is completely unable to evolve to support new requirements.</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">
to fit in new requirements results in buggy software. That being said, I<br>
usually don't like to rebuild a project from scratch. If I can I try to<br>
refactor as much as possible first. However, in this case we have a<br>
particular set of requirements that changes the game. Particularly,<br>
operator requirements have not been given the attention they deserve.<br>
</blockquote>
<div>Operator requirements really don't change the game here.</div>
<div>You're right that operator requirements were not given the attention. </div>
<div>It's not because developers of lbaas have not thought about it, it's because we were limited in dev and core reviewing</div>
<div>resources, so implement </div>
<div>But what is more important, operator requirements mostly doesn't affect tenant API that we were discussing.</div>
<div>That's true that almost none of them are addressed by existing code base, but it only means that it should be implemented.</div>
<div><br>
</div>
<div>When talking about existing code base I'd expect the following questions before any decision is made:</div>
<div><br>
</div>
<div>1) how can we do (implement) X with existing code base?</div>
<div>2) if we can't do X, is it possible to fix the code in a simple way and just implement X on top of existing?</div>
<div><br>
</div>
<div>If both answers are "No", and X is really impossible with existing code base - that could be a reason to deeply revise it.</div>
<div>Looking at operator requirements I don't see a single one that could lead to that.</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">
Because several of us have been spending large amounts of time on API<br>
proposals, and because we can safely assume that most operational<br>
requirements are abstracted into the driver layer I say we continue the<br>
conversation around the different proposals since this is the area we<br>
definitely need consensus on. So far there are three proposals--Stephen's,<br>
Rackspace's and Eugene's. </blockquote>
<div>I'd like to comment that my proposal is actually a small part of Stephen's that touches the core lbaas API only.</div>
<div>So i would not treat it separately in this context.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Eugene.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span></div>
</div>
</span>
</body>
</html>