<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi ,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">As Stephen +1 to everything Jorge said. Another concern is that some decisions impacting LBaaS operator requirements (e.g SSL, flavor framework, service chaining)
are discussed/decided in the advanced services group (see <a href="https://wiki.openstack.org/wiki/Neutron/AdvancedServices">
https://wiki.openstack.org/wiki/Neutron/AdvancedServices</a>). Vijay did an excellent job involving us in LBaaS in the SSL discussion. Thanks, Vijay!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I am wondering how the process is supposed to work between the two groups. There is a lot of overlap right now and decisions in the areas currently discussed
in Advanced Services impact our operator requirements for load balancing a great deal. Kyle, I am wondering if you can provide some guidance what your vision is how LBaaS operator requirements get considered in other parts of Neutron.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">German<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Stephen Balukoff [mailto:sbalukoff@bluebox.net]
<br>
<b>Sent:</b> Wednesday, April 30, 2014 5:07 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Jorge!<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">+1 to everything you just said. In fact, I think you said essentially what I was trying to last week with 100% less drama.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Stephen<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Apr 30, 2014 at 3:26 PM, Jorge Miramontes <<a href="mailto:jorge.miramontes@rackspace.com" target="_blank">jorge.miramontes@rackspace.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">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">jorge.miramontes@RACKSPACE.COM</a>><br>
wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><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">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">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><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Stephen Balukoff <br>
Blue Box Group, LLC <br>
(800)613-4305 x807 <o:p></o:p></p>
</div>
</div>
</body>
</html>