<div dir="ltr">Hi,<div><br></div><div>A couple of comments:</div><div class="gmail_extra"><br><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">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><div><br>
</div>
<div>To be perfectly clear we are not advocating "starting from scratch". If it has come out that way then let me be the first to correct that on behalf of my team. In reality, defining a brand new API specification is irrelevant to implementation. </div>
</div></blockquote><div>Probably that's what I personally can't agree with: "defining brand new API". API is the most rigid part of the system. Redefining it completely renders most of the rest parts obsolete. Btw, there is a code outside LBaaS (vmware service plugin) that was built using LBaaS API.</div>
<div>Funnily, the problem with current API is that it was initially made similar to Atlas where single pool per LB is assumed. That's a quite small, but nasty issue that needs to be fixed to allow to go with most of new requirements. </div>
<div>It was well-understood that existing API is limiting further development, but bw-compatible evolution was always kept in mind.</div><div>And btw I would not call L7, SSL, operator's part of API a "brand new" even if these are completely new parts; that is an extension of existing, not a redefinition.</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 class=""><span><blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5"><div><div><div dir="ltr"><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">
<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>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
</div><div>While overall design may have been thought out long ago it doesn't mean that the discussion should be closed. By saying this, you are implying that newcomers are not welcome those discussions. At least, that is how your statement rubs off on me. I'll give
 you the benefit of the doubt to correct my understanding of that.</div></div></blockquote><div>Well, by saying 'without <span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;font-size:14px">thinking about overall design' one might understand that you assume that such thinking was not done so far. So I just meant </span>that we have been thinking of overall design, so it would be incorrect to say that existing code base was the blind implementation swinging towards nowhere. </div>
<div>The opinion of "newcomers" is definitely welcomed, especially about requirements and use cases.</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 class="">
<div><br>
</div>
<span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<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"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div><div><div><br></div></div></div></div></blockquote>
<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>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
</div><div>The fact that there are no core developers on Neutron LBaaS is concerning to say the least even though there are a large number of people/companies now involved. I have other thoughts on this but will leave that for another day.</div>
</div></blockquote><div>It's not exactly that. It's an already formed developer community with their views and opinions; you can't just say to anyone 'if you don't discuss lbaas - don't review the lbaas code', right?</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 class=""><span><blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5"><div><div><div dir="ltr"><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">
<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>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
</div><div>Correct. We are mostly interested in using a pure open-source backend. HAProxy is definitely where we will be starting.</div></div></blockquote><div>Good. I'm looking forward to see what fundamental issues you see with haproxy driver.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div></div></div>