<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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>On Fri, Apr 25, 2014 at 4:03 AM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<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 dir="ltr">Hi Stephen,<div><br></div><div>Thanks for the great document. As I promised, I'll try to make a few action items out if it.</div>
<div>First of all, I'd like to say that the API you have proposed is very close to what is proposed in the blueprint <a href="https://review.openstack.org/#/c/89903/" target="_blank">https://review.openstack.org/#/c/89903/</a> with several differences I'd like to address here and make them action items.</div>
</div></blockquote><div><br></div></div><div>Ok, the above blueprint was uploaded on April 23rd, literally the day I sent my API proposal to the mailing list. And this was after it was known via the action items in the previous week's IRC meeting that my team and I would be working hard over the next week to produce an API proposal revision, based on the excellent work of the Rackspace team from the previous week.</div>
<div><br></div><div>I can understand having a "plan B" in case I missed a deadline there (after all, I wasn't all that confident we'd get it done in time, but I worked through the weekend and pulled some very long days to get it done)-- but it's pretty offensive to me to realize that the action items from the previous week's meeting apparently weren't being taken seriously. </div>
</div></div></div></blockquote><div><br>I'm not sure which of my actions exactly has offended you, was it submitting a blueprint to neutron-spec? <br>I've been working on the several proposals, including the one on review since the start of Icehouse, preparing wikis, docs, and even an attempt to actually implement the proposal, so I'm not sure what exactly I did wrong.</div>
<div>I was not thinking about beating anyone to submit blueprint first, it was on launchpad since the end of havana anyway and i've just renewed it and followed the new process.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>That not only was there apparently never an intent to seriously consider my proposal, but now, if I want to be heard, I'm going to have to familiarize myself with your proposal and fight tooth and nail to be heard to fix any brokenness I will almost certainly find in it. And I have to do this with very little confidence that my voice is going to be heard.</div>
</div></div></div></blockquote><div> </div><div>I think our disconnect comes from the fact that whole discussion that started in the end of Havana from fixing the API in the way that L7 & multiple listeners are possible, came to the discussion of 'what lbaas API of the dream should look like'.</div>
<div>Your document does great job of addressing the latter, but it's hardly a single action item/single blueprint/single patch.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>Gee. Thanks.</div></div></div></div></blockquote><div>Sorry, In fact I should have meant that some of those action items are for me actually, your doc is very detailed, while spec on review yet is not. I'll try to bring it to some accordance to your doc.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<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 dir="ltr">
<div>So, first of all, I think that API described in the doc seems to account for all cases we had in mind, i didn't check on case-by-cases basis, it's just a first glance impression looking at REST resource set and their attributes. </div>
</div></blockquote><div><br></div></div><div>As an aside, let's us please, please, please get these use cases out of being "in mind" and into a unified, digestible, revision-controlled document. I guarantee you haven't thought of some of the use cases I have in mind.</div>
<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 dir="ltr"><div>General idea of the whole API/obj model improvement is that we create a baseline for all advanced features/usecases that we have in the roadmap. Which means that those features then can be added incrementally. Incrementally means that resources or attributes might be added, but workflow remains and backward compatibility is preserved. That was not the case with multiple listeners and L7.</div>
</div></blockquote><div><br></div></div><div>I would argue that that wasn't the case for SSL either in the old model. And even the model I proposed doesn't address HA yet. </div></div></div></div></blockquote><div>
The model shouldn't immediately address HA. You just have to make sure that once you decided to add HA, you don't have to redesign the rest of it (but that probably requires some ideas on how to add HA)</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>It's assumed that the object model proposed won't affect the ability of vendors to implement HA in whatever way makes sense for their organization... but we don't really know that until we see some rough models on that front.</div>
<div><br></div><div>Anyway, I think the point remains that the whole reason for the API and object model revision was to be more forward thinking, specifically about those features that are currently sorely lacking from Neutron LBaaS, and which both users and operators clearly need before the solution can be deployed on a wide scale.</div>
<div><br></div><div>And yes, of course this is a design that will necessarily be implemented incrementally! First priority should be to deliver at least the same level of functionality that the old api / object model delivers. But, again, I think it's a really good idea to be forward thinking about these sorts of things. If I'm planning a road trip from Denver to New York, I like to consider at a high level at least what kind of route will take me there (so I can be sure that I don't realize 500 miles into the trip that I've been driving toward L.A. the whole time).</div>
<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 dir="ltr"><div>So, a couple on general comments:</div>
<div><br></div><div>1. Whole discussion about API/obj model improvement had the goal of allowing multiple pools and multiple listeners.</div></div></blockquote><div><br></div></div><div>This is news to me. If we aren't going to be thinking about SSL and L7 also, at least, then there really was no reason to propose drastic changes to the API / object model. </div>
</div></div></div></blockquote><div>Stephen, L7 and multiple listeners were the reasons to revise the model. Let's just separate the work of improving existing API/obj model from additional action items, as i said above. L7 and SSL could be worked on in parallel, but only after deal with Pools/Vips/Listeners is fixed.</div>
<div>Think of it from implementation perspective: how can one work on SSL if there still not fixed whether we have listeners or just VIPs? same for L7.</div><div><br></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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>And just what have we been discussing on this mailing list and in the IRC meetings for the last couple months? Again, I think it's a little unfair to criticize the API proposal I've made because it delivers features that people have been asking for for a long time (and that are already present, functional, and well understood in other load balancer implementations.)</div>
</div></div></div></blockquote><div>I don't remember criticizing it, I actually think it is a great and detailed description, good API; in the part that is about VIP/listeners/Pools it is nearly the same as the blueprint on spec-review, other parts such as L7 stuff also makes sense to me, but that's certainly what I didn't plan to address in my bp, which has much much more limited scope.</div>
<div><br></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 dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">
<div><br></div><div>Also, please understand that "multiple pools" is L7! Can anyone name a use case where multiple back-end pools are used on a single listener that doesn't involve some L7 logic in there somewhere?</div>
</div></div></div></blockquote><div>Right, it is L7. And I'm not trying to add L7, I'm just getting rid of 'Pool as the root object' that has prevented L7 from being implemented, that is in scope of my proposal. Actually adding L7 is out of scope of it.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<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 dir="ltr"><div>For that purpose loadbalancer instance might be an extra. The good thing about 'loadbalancer' is that it can be introduced in the API in incremental way. </div>
</div></blockquote><div><br></div></div><div>Right. You might also notice that in the diagram, it's grayed out and there are notes indicating that work needs to be done to flesh out the concept based on discussion around HA functionality and operator concerns. Again, this is an attempt by me to be more forward-thinking.</div>
<div><br></div><div>There is only one attribute (of a VIP) that references the "load balancer" concept as defined in the glossary (also linked). Yes, it can be removed from this API proposal and added back in again later when / if the discussion around HA actually happens.</div>
<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 dir="ltr">
<div>So, VIP+listeners itself is already quite flexible construct (where VIP is a root object playing loadbalancer role) that addresses our immediate needs.</div><div>So I'd like to extract loadbalancer API and corresponding use cases in another blueprint. </div>
<div>You know that loadbalancer concept has raised very heated discussions so it makes sense to continue discussing it separately, keeping in mind that introducing loadbalancer is not very complex and it may be done on top of the VIPs/listeners API</div>
</div></blockquote><div><br></div></div><div>Also, I notice this is a pretty stark 180-degree turn around on your position on this from previous weeks' discussions. It's OK to change one's mind on these things, but again, this leads me to believe that this is being forced from outside of the Neutron LBaaS sub-project.<br>
</div></div></div></div></blockquote><div>Not exactly. I was advocating approaches #2 and #3 from the beginning ( <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion</a> ) because both of them address requirements for multiple tcp endpoints and L7 (structurally they are close).</div>
<div>I agree that #2 is even more flexible, but the discussion about the loadbalancer instance has been kept for more than release cycle for now without much result; since #3 addresses the requirements also - I'm ok with that.<br>
</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>
</div><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 dir="ltr"><div>2. SSL-related objects. SSL is rather big deal, both from API and object model, it was a separate blueprint in Icehouse and i think it makes sense to work separately on it.</div>
<div>What I mean is that ssl don't affect core API (VIPs/listeners/pools) other than adding some attributes to listeners.</div></div></blockquote><div><br></div></div><div>Ok, again, from my perspective this is a stark change from how this has been discussed in previous weeks on this mailing list and in the IRC meetings. I thought it hadn't been decided exactly how SSL was going to be done yet. </div>
</div></div></div></blockquote><div>Something could be called 'decided' when it lands into the code repository. There has been some work already done on SSL on both design and implementation front though.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>(There was very little discussion of this on the mailing list, and certainly nothing conclusive. And even the blueprint references a gerrit patch "discussion" that essentially is just CI systems checking in. In fact the only actual design discussion of this in months appears to have been happening exclusively on the mailing list: <a href="http://stackalytics.com/report/blueprint/neutron/lbaas-ssl-termination" target="_blank">http://stackalytics.com/report/blueprint/neutron/lbaas-ssl-termination</a> )<br>
<br>If you want to claim that "silence implies consent" with the design, this seems disingenuous to me when much more broad design discussions (which ultimately affect the SSL design) are happening at the same time. It's like arguing about how the decks are going to be laid out when we haven't even decided which kind of ship we're building yet.</div>
</div></div></div></blockquote><div>I'm not sure that I'm arguing here at all. As you probably noticed, I didn't participate much in ssl-related discussions.</div><div>Speaking of SSL - we have a few few project-wise issues such as lack of secure storage, lack of secure messaging, requirement to have opensource impl of SSL API (which yet to be added). </div>
<div>There's also a patch on review that is worth looking at, because someone has already put efforts into both design and code. </div><div>And before throwing away all those efforts we need to be sure it completely not suitable with the rest of API.</div>
<div><br></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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 dir="ltr"><div>3. L7 is also a separate work, it will not be accounted in 'API improvement' blueprint. You can sync with Samuel for this as we already have pretty detailed blueprints on that.</div>
</div></blockquote><div><br></div></div><div>Please provide an example of how "multiple pools" will actually be used without L7.<br></div></div></div></div></blockquote><div>As said above, the bp targets just the baseline for L7: removing 'root object' role from the Pool, to actually allow multiple pools in configuration when L7 rules are added.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br>And again: "Let's move the discussion off the mailing list where it's been happening over to the system where apparently others have been pressing forward without the obvious knowledge or consent of the people having the discussion. Oh, and by the way, because we've already written code here, a lot of what you propose is tacitly no longer up for discussion."</div>
<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 dir="ltr">
<div>4. Attribute differences in REST resources.</div><div>This falls into two categories: </div><div>- existing attributes that should belong to one or another resource, </div></div></blockquote><div><br></div></div><div>
The devil's in the details here. I was very specific about which attributes belong to which objects because getting this wrong has serious implications for use cases. (For example, if "neutron_subnet" is an attribute of a pool, then this implies all members of the pool must be in the same neutron_subnet. And this breaks the use case that was described on the mailing list during the SSL re-encryption discussion where some members are in the same subnet, and some are across the internet on the other side of a VPN or otherwise.)<br>
</div></div></div></div></blockquote><div>Right. I should have said it's a work item for me - to look closely through your doc and address the differences. Also, that is exactly the kind of work item where gerrit helps a lot.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>
<br>You also need to define which attributes are immutable after creation of the object, and which can be changed with later updates (and how). This also has implications for use cases.</div></div></div></div></blockquote>
<div>Well, this is usually defined in the code, I can add this to the spec as well. I hoped to avoid duplicate work.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>If your proposal doesn't define this level of detail, then your proposal isn't addressing the use cases and is therefore incomplete.</div>
</div>
</div></div></blockquote><div>I'm working on that.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 dir="ltr"><div>- attributes that should be added (e.g. they didn't exist in current API)</div></div></blockquote><div><br></div></div><div>Right. As I said last week, my intention was to try to address as many concerns and feature requests from the mailing list discussions, wiki pages, and google documents / spreadsheets as possible. I was hoping to take a stab at HA as well, but the result of that discussion so far is that we're nowhere near having any idea how to accomplish this in a way that is going to be generically possible for all operators.</div>
<div><br></div><div>I mean: You all do realize that if there's a key missing feature that one operator absolutely needs in order to continue their business operations, that isn't addressed in our proposals... then that operator is NOT going to use our product, right? </div>
</div></div></div></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"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div>And that doesn't mean you need to offer all features out of the gate-- but you ought to have put some thought into how you're going to do it when the time comes. This proposal is trying to be that plan for how we're eventually going to do it. It will, of course, be developed incrementally.</div>
</div></div></div></blockquote><div>So, what are we arguing about? I'm just doing the small part that fixes relationship issue with the obj model.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>It is true that I haven't had the time to fill out all the use cases we thought about, or that became apparent from mailing list discussions as we were writing our API revision proposal-- our main drive was to get the proposal out the door. My plan was (and still is) to back-fill these use cases in the right place (which I'm no longer sure is the google doc that Samuel created, or the gerrit system) once we got the API proposal out. So I do apologize that I'm making reference to stuff that has been considered but not shared thus far and realize that not having it in the shared document weakens my position. I had to sleep.</div>
<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 dir="ltr">
<div>The first class is better to be addressed in the blueprint review. The second class could be a small action items/blueprints or even bugs. </div></div></blockquote><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 dir="ltr"><div><font face="arial, helvetica, sans-serif">Example:</font></div><div>
<font face="arial, helvetica, sans-serif"> 1) <span style="white-space:pre-wrap;background-color:transparent">"custom_503" - that attribute deserves it's own miniblueprint, I'd keep it out of scope of 'API improvement' work.</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span style="white-space:pre-wrap;background-color:transparent"> 2) ipv6_subnet_id/addressv6 - that IMO also deserves it's own miniblueprint (whole thing about ipv6 support)</span></font></div>
</div></blockquote><div><br></div></div><div>Yep, custom_503 is extremely minor, and its use case is "User would like to have custom error 503 page displayed on HTTP / HTTPS requests when no servers are available in the back-end pool(s)."</div>
<div><br></div><div>IPv6 discussions are quite a bit more involved-- but I will note that at least one major vendor mentioned this as a high priority item, (and it turns out it's easy to address in the model) which is why we threw it in this proposal.</div>
</div></div></div></blockquote><div>They're welcome to propose bp on the ipv6 support and implement it.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<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 dir="ltr"><div><font face="arial, helvetica, sans-serif"><span style="white-space:pre-wrap;background-color:transparent">So, I'd like to make the following action items out of the document:</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span style="white-space:pre-wrap;background-color:transparent"><br></span></font></div><div><font face="arial, helvetica, sans-serif"><span style="white-space:pre-wrap;background-color:transparent">1. Extract 'core API' - VIPs/Listeners/Pools/Members/Healthmonitors.</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span style="white-space:pre-wrap;background-color:transparent">This action item is actually the blueprint that I've filed and that's what I'm going to implement</span></font></div>
</div></blockquote><div><br></div></div><div>"that's what I'm going to implement"-- ie. Discussion is closed on this.</div></div></div></div></blockquote><div>I'm not sure I get your point here. Just reiterating: 'root object' moved to VIP, listeners added - that's what i'm addressing.</div>
<div>Once we have that, you can actually develop patches on everything else and be sure that you have not redone everything if underlying design is changed.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 dir="ltr"><div><font face="arial, helvetica, sans-serif"><span style="white-space:pre-wrap;background-color:transparent">2. Work on defining single-call API that goes along with single object core API (above)</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span style="white-space:pre-wrap;background-color:transparent">Your document already does a very good job on this front.</span></font></div></div></blockquote><div><br></div>
</div><div>Thank you. It's nice to know some of my work is being paid attention to.</div><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 dir="ltr"><div><font face="arial, helvetica, sans-serif"><span style="white-space:pre-wrap;background-color:transparent">3. Extract 'Loadbalancer' portion of API into additional Doc/blueprint. I deserves it's own discussion and use cases.</span></font></div>
<div><font face="arial, helvetica, sans-serif"><span style="white-space:pre-wrap;background-color:transparent">I think separating it will </span></font><span style="white-space:pre-wrap;font-family:arial,helvetica,sans-serif">also </span><span style="white-space:pre-wrap;background-color:transparent;font-family:arial,helvetica,sans-serif">help to reduce discussion contention.</span></div>
</div></blockquote><div><br></div></div><div>Fine, though I would say that justifying the "VIP-centric" approach becomes more difficult if we're not starting to think about how we're going to address operator concerns (like, say, HA) and how these potentially intersect and/or interface with user concerns.</div>
</div></div></div></blockquote><div>Well, I'd also would like to hear from those, who don't want neutron to provide 'virtualized appliance' functionality.</div><div>I think that meanwhile we may treat VIP as 'loadbalancer' object and apply HA features directly to it.</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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<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 dir="ltr"><div><span style="white-space:pre-wrap;background-color:transparent;font-family:arial,helvetica,sans-serif">4. Work with </span><a href="https://review.openstack.org/#/c/89903/" target="_blank">https://review.openstack.org/#/c/89903/</a> to define proper attribute placement of existing attributes</div>
</div></blockquote><div><br></div></div><div>Given that you totally ignored (or planned to ignore) the work you knew I was doing on this API proposal in writing the above blueprint... does my opinion on the attribute placement even matter at this point?</div>
</div></div></div></blockquote><div>Sorry again for offensive phrasing, i didn't mean that. That was meant to be is a work item more for me than for you, but i hoped to get some inline comments on gerrit.</div><div><br>
</div><div>At the end I'd like to emphasize that I was not planning to implement everything and account for all cases.</div><div>The scope is to add listeners and move 'root object' role from Pool to the VIP, that's it, and that's what is on spec review.</div>
<div><br></div><div>Thanks,</div><div>Eugene.</div></div></div></div>