<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>