<div dir="ltr">Jorge,<div><br></div><div>In looking over your API proposal linked above, have things significantly changed there since you sent it out two weeks ago?  (And if so, which parts should I take a look at again?)</div>
<div><br></div><div>Thanks,</div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 30, 2014 at 5:07 PM, Stephen Balukoff <span dir="ltr"><<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Jorge!<div><br></div><div>+1 to everything you just said. In fact, I think you said essentially what I was trying to last week with 100% less drama.</div>
<div><br></div><div>I'll work to add workflows to my proposal, but please note it's late on a Wednesday and tomorrow's IRC meeting is awfully early in my time zone. I probably won't have workflow documentation done in time.</div>

<div><br></div><div>Thanks,</div><div>Stephen</div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Wed, Apr 30, 2014 at 3:26 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oops! Everywhere I said Samuel I meant Stephen. Sorry you both have SB as<br>
you initials so I got confused. :)<br>
<br>
Cheers,<br>
--Jorge<br>
<br>
<br>
<br>
<br>
On 4/30/14 5:17 PM, "Jorge Miramontes" <<a href="mailto:jorge.miramontes@RACKSPACE.COM" target="_blank">jorge.miramontes@RACKSPACE.COM</a>><br>
wrote:<br>
<div><div><br>
>Hey everyone,<br>
><br>
>I agree that we need to be preparing for the summit. Using Google docs<br>
>mixed with Openstack wiki works for me right now. I need to become more<br>
>familiar the gerrit process and I agree with Samuel that it is not<br>
>conducive to "large" design discussions. That being said I'd like to add<br>
>my thoughts on how I think we can most effectively get stuff done.<br>
><br>
>As everyone knows there are many new players from across the industry that<br>
>have an interest in Neutron LBaaS. Companies I currently see<br>
>involved/interested are Mirantis, Blue Box Group, HP, PNNL, Citrix,<br>
>eBay/Paypal and Rackspace. We also have individuals involved as well. I<br>
>echo Kyle's sentiment on the passion everyone is bringing to the project!<br>
>Coming into this project a few months ago I saw that a few things needed<br>
>to be done. Most notably, I realized that gathering everyone's<br>
>expectations on what they wanted Neutron LBaaS to be was going to be<br>
>crucial. Hence, I created the requirements document. Written requirements<br>
>are important within a single organization. They are even more important<br>
>when multiple organizations are working together because everyone is<br>
>spread out across the world and every organization has a different<br>
>development process. Again, my goal with the requirements document is to<br>
>make sure that everyone's voice in the community is taken into<br>
>consideration. The benefit I've seen from this document is that we ask<br>
>"Why?" to each other, iterate on the document and in the end have a clear<br>
>understanding of everyone's motives. We also learn from each other by<br>
>doing this which is one of the great benefits of open source.<br>
><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"? If this project were a completely new piece of<br>
>software I would argue that we iterate on individual features based on<br>
>anecdotal information. In essence I would argue an agile approach.<br>
>However, most of the companies involved have been operating LBaaS for a<br>
>while now. Rackspace, for example, has been operating LBaaS for the better<br>
>part of 4 years. We have a clear understanding of what features our<br>
>customers want and how to operate at scale. I believe other operators of<br>
>LBaaS have the same understanding of their customers and their operational<br>
>needs. I guess my main point is that, collectively, we have data to back<br>
>up which requirements we should be working on. That doesn't mean we<br>
>preclude requirements based on anecdotal information (i.e. "Our customers<br>
>are saying they want new shiny feature X"). At the end of the day I want<br>
>to prioritize the community's requirements based on factual data and<br>
>anecdotal information.<br>
><br>
>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. 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. In my<br>
>experience, I would argue that 99% of the time duct-taping existing code<br>
>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>
><br>
>I think of Openstack as being cloud software that is meant to operate at<br>
>scale and have the necessary operator tools to do so. Otherwise, why do we<br>
>have so many companies interested in Openstack if you can't operate a<br>
>cloud that scales? In the case of LBaaS, user/feature requirements and<br>
>operator requirements are not necessarily mutually exclusive. How you<br>
>design the system in regards to one set of requirements affects the design<br>
>of the system in regards to the other set of requirements. SSL<br>
>termination, for example, affects the ability to scale since it is CPU<br>
>intensive. As an operator, I need to know how to provision load balancer<br>
>instances efficiently so that I'm not having to order new hardware more<br>
>than I have to. With this in mind, I am assuming that most of us are<br>
>vendor-agnostic and want to cooperate in developing an open source driver<br>
>while letting vendors create their own drivers. If this is not the case<br>
>then perhaps a lot of the debates we have been having are moot since we<br>
>can separate efforts depending on what driver we want to work on. The only<br>
>item of Neutron LBaaS that we need to have consensus on then is the API<br>
>(web app, database, messaging system, etc.). Keep in mind that the API<br>
>implies what feature/user requirements are satisfied, but no so much for<br>
>operator requirements. I think this is one reason why we have been working<br>
>on API proposals. Samuel, thank you for the time you spent on your<br>
>proposal as we know how much time and effort it takes.<br>
><br>
>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. To date, we honestly haven't had an actual<br>
>discussion on the pros and cons of each proposal. To give structure to<br>
>this we here at Rackspace have been going to great lengths to make sure we<br>
>have enough tangible documentation in order to clearly convey our<br>
>thoughts. We also went to great lengths to satisfy the user/feature<br>
>requirements in our API. Here is what we have done:<br>
><br>
>- An API specification located here ==><br>
><a href="https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWy" target="_blank">https://docs.google.com/document/d/1mTfkkdnPAd4tWOMZAdwHEx7IuFZDULjG9bTmWy</a><br>
>X<br>
>e-zo/edit<br>
>- Single API call workflows & multiple API call workflows of each of the<br>
>use cases (#1 through #9 for now) from<br>
><a href="https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXu" target="_blank">https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXu</a><br>
>S<br>
>INis/edit#heading=h.48fieovwttzg. Our workflows are located here ==><br>
><a href="https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0" target="_blank">https://drive.google.com/#folders/0B2r4apUP7uPwRVc2MzQ2MHNpcE0</a><br>
>- A lightweight proof of concept that is in the works so that people that<br>
>need to actually send requests to an API to believe in it can do so. We<br>
>will send an update in a few days when this POC is complete.<br>
><br>
>In order to fairly compare proposals I think it would be nice if each<br>
>proposal give workflows on how their API will operate. This is isn't<br>
>necessary but I think it will definitely give structure in any discussions<br>
>we have when comparing. If others have thoughts on how to compare the<br>
>proposals on equal footing then by all means speak up.<br>
><br>
>Once we come to a consensus on the API then we can figure out how to make<br>
>iterative changes in order to get the API to the consensus state. That is<br>
>a separate conversation in my mind. First we need to agree on a spec<br>
>without the confines of looking at current implementation.<br>
><br>
><br>
>Cheers,<br>
>--Jorge<br>
><br>
><br>
>P.S. Sorry for the delay in responding to the ML. Just reading them takes<br>
>several hours.<br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br><a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a>

</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div>