<div dir="ltr">Hi guys!<div><br></div><div>This is a great discussion, and I'm glad y'all have been participating in it thus far, eh! Thanks also for you patience digesting my mile long posts.</div><div><br></div><div>
My comments are in-line:</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 3:47 PM, Youcef Laribi <span dir="ltr"><<a href="mailto:Youcef.Laribi@citrix.com" target="_blank">Youcef.Laribi@citrix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi guys,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I have been catching up on this interesting thread around the object model, so sorry in advance to jump in late in this debate, and if I missed some of the
 subtleties of the points being made so far. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I tend to agree with Sam that the original intention of the current object model was never tied to a physical deployment. We seem to be confusing the tenant-facing
 object model which is completely logical (albeit with some “properties” or “qualities” that a tenant can express) from the deployment/implementation aspects of such a logical model (things like cluster/HA, one vs. multiple backends, virtual appliance vs. OS
 process, etc). We discussed in the past, the need for an Admin API (separate from the tenant API) where a cloud administrator (as opposed to a tenant) could manage the deployment aspects, and could construct different offerings that can be exposed to a tenant,
 but in the absence of such as admin API (which would necessarily be very technology-specific), this responsibility is currently shouldered by the drivers.</span></p></div></div></blockquote><div><br></div><div>Looking at the original object model but not having been here for the origin of these things, I suspect the original intent was to duplicate the functionality of one major cloud provider's load balancing service and to keep things as simple as possible. Keeping things as simple as they can be is of course a desirable goal, but unfortunately the current object model is too simplistic to support a lot of really desirable features that cloud tenants are asking for. (Hence the addition of L7 and SSL necessitating a model change, for example.)</div>
<div><br></div><div>I'm still of the opinion that HA at least should be one of these features-- and although it does speak to topology considerations, it should still be doable in a purely logical way for the generic case. And I feel pretty strongly that intelligence around core features (of which I'd say HA capability is one-- I know of no commercial load balancer solution that doesn't support HA in some form) should not be delegated solely to drivers. In addition to intelligence around HA, not having greater visibility into the components that do the actual load balancing is going to complicate other features as well--  like auto-provisioning of load balancing appliances or pseudo-appliances, statistics and monitoring, and scaling.  And again, the more of these features we delegate to drivers, the more clients are likely to experience vendor lock-in due to specific driver implementations being different.</div>
<div><br></div><div>Maybe we should revisit the discussion around the need for an Admin API? I'm not convinced that all admin API features would be tied to any specific technology. :/  Most active-standby HA configurations, for example, use some form of floating IP to achieve this (in fact, I can't think of any that don't right now). And although specific implementations of how this is done will vary, a 'floating IP' is a common feature here.</div>
<div> <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">IMO a tenant should only care about whether VIPs/Pools are grouped together to the extent that the provider allows the tenant to express such a preference.
 Some providers will allow their tenants to express such a preference (e.g. because it might impact cost), and others might not as it wouldn’t make sense in their implementation.</span></p></div></blockquote><div><br></div>
<div>Remind me to tell you about the futility of telling a client what he or she should want sometime. :)</div><div><br></div><div>In all seriousness, though, we should come to a decision as to whether we allow a tenant to make such decisions, and if so, exactly how far we let them trespass onto operational / implementation concerns. Keep in mind that what we decide here also directly impacts a tenant's ability to deploy load balancing on a specific vendor's appliance. (Which, I've been lead to believe, is a feature some tenants are going to demand.)</div>
<div><br></div><div>I've heard some talk of a concept of 'flavors' which might solve this problem, but I've not seen enough detail about this to be able to register an opinion on it. In the absence of a better idea, I'm still plugging for that whole "cluster + loadbalancer" concept alluded to in my #4.1 diagram in this e-mail thread. :)</div>
<div> <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Also the mapping between pool and backend is not necessarily 1:1, and is not necessarily at the creation time of pool, as this is purely a driver implementation
 decision (I know that currently implementations are like this, but another driver can choose a different approach). A driver could for example delay mapping a pool to a backend, until a full LB configuration is completed (when pool has members, and a VIP is
 attached to the pool). A driver can also move these resources around between backends, if it finds out, it put them in a non-optimal backend initially. As long as the logical model is realized and remains consistent from the tenant point of view, implementations
 should be free to achieve that goal in any way they see fit.</span></p></div></div></blockquote><div><br></div><div>I agree partially, though there are technological considerations which will influence this of course. (eg. Sometimes it's going to be really important that that 'http' and 'https' listener be collocated on the same back-end because they have to share the same IP address.)</div>
<div><br></div><div>I would also argue that specifying a given HA topology is something tenants should generally be allowed to do. (Though not necessarily which specific devices get used, assuming there are a fleet of capable devices deployed.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> </span><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"> Eugene Nikanorov [mailto:<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>] </span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<b>Sent:</b> Wednesday, February 19, 2014 8:23 AM<br>
<b>To:</b> Samuel Bercovici<br>
<b>Cc:</b> OpenStack Development Mailing List; Mark McClain; Salvatore Orlando; <a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>; Youcef Laribi; Avishay Balderman<br>
<b>Subject:</b> Re: [Neutron][LBaaS] Object Model discussion<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Hi Sam,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">My comments inline:<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Feb 19, 2014 at 4:57 PM, Samuel Bercovici <<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think we mix different aspects of operations. And try to solve a non “problem”.</span><u></u><u></u></p>

</div>
</div>
<div>
<p class="MsoNormal">Not really, Advanced features we're trying to introduce are incompatible by both object model and API.</p></div></div></div></div></div></div></div></div></blockquote><div> </div><div>+1 </div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div><div class="h5"><div><div><div><div><p class="MsoNormal">
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">From APIs/Operations we are mixing the following models:</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">1.</span><span style="font-size:7.0pt;color:#1f497d">      
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Logical model (which as far as I understand is the topic of this discussion) - tenants define what they need logically vip</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">à</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">default_pool,
 l7 association, ssl, etc.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">That's correct. Tenant may or may not care about how it is grouped on the backend. We need to support both cases. </p></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>
+1</div><div><br></div><div>Also, I would argue that specific HA topologies (though not necessarily the devices they map to) are still part of that 'logical model'. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><div><div class="h5"><div><div><div><div><p class="MsoNormal"><u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">2.</span><span style="font-size:7.0pt;color:#1f497d">      
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Physical model – operator / vendor install and specify how backend gets implemented.</span></p></div></div></blockquote>
</div></div></div></div></div></div></div></blockquote><div>I talked about the benefits of the cloud from the perspective of the operator / vendor in a previous post. In any case, to realize many of these benefits the cloud needs to be aware of physical components, though specific intelligence about these will generally be hidden from tenants.</div>
<div><br></div><div>(Maybe I should have been talking about the need for a "cloud administrator's" API or interface?)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><div><div class="h5"><div><div><div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
</span><u></u><u></u></p>
<p><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">3.</span><span style="font-size:7.0pt;color:#1f497d">      
</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Deploying 1 on 2 – this is currently the driver’s responsibility. We can consider making it better but this should not impact the logical model.</span><u></u><u></u></p>

</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">I think grouping vips and pools is important part of logical model, even if some users may not care about it.</p></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>+1</div>
<div><br></div><div>Just because some users don't care doesn't mean all users won't care. Again, in my experience, user's don't care until they do (ie. a specific feature becomes important to their business needs that was previously unimportant). So, I'm generally in favor of allowing for the simplest workflow possible for users (and following the principle of least surprise when picking defaults on their behalf), but doing this in a model which also supports advanced features without having to resort to annoying hacks (like delegating major features to drivers. :P )</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="h5"><div><p class="MsoNormal"><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u>  </p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><p class="MsoNormal"><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think this is not a “problem”.
</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In a logical model a pool which is part of L7 policy is a logical object which could be placed at
 any backend and any existing vip</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">ßà</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">pool and accordingly configure the backend that those vip</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">ßà</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">pool
 are deployed on.</span><u></u><u></u></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> That's not how it currently works - that's why we're trying to address it. Having pool shareable between backends at least requires to move 'instance' role from the pool to some other entity, and also that changes a number of API aspects.</p>
</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div><div class="h5"><div><div><div><div>
<p class="MsoNormal"><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If the same pool that was part of a l7 association will also be connected to a vip as a default pool,
 than by all means this new vip</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">ßà</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">pool pair can be instantiated into some back end.</span><u></u><u></u></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The proposal to not allow this (ex: only allow pools that are connected to the same lb-instance to
 be used for l7 association), brings the physical model into the logical model.</span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">So proposal tries to address 2 issues: <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">1) in many cases it is desirable to know about grouping of logical objects on the backend </p></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>...and occasionally dictate that grouping from the API.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div><div class="h5"><div><div><div><div><p class="MsoNormal">
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2) currently physical model implied when working with pools, because pool is the root and corresponds to backend with 1:1 mapping<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think that the current logical model is fine with the exception that the two way reference between
 vip and pool (vip</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">ßà</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">pool) should be modified with only vip pointing to a pool (vip</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">à</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">pool)
 which allows reusing the pool with multiple vips. </span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">Reusing pools by vips is not as simple as it seems. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If those vips belong to 1 backend (that by itself requires tenant to know about that) - that's no problem, but if they don't, then:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">1) what 'status' attribute of the pool would mean?</p></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Presumably if the pool is down for one back-end, it's down for all the back-ends. But you're right that there might be cases (eg. network connectivity problem) where a pool is down for one back-end but not another.  Maybe the question of pool status only makes sense in the context of a specific listener?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div><div class="h5"><div><div><div><div><p class="MsoNormal">
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2) how health monitors for the pool will be deployed? and what their statuses would mean?</p></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>To be frank, I don't understand why healthmonitors aren't just extra attributes of the pool object. (Does anyone know of any case where having multiple healthmonitors per pool makes sense?) Also, isn't asking the status of a healthmonitor functionally equivalent to asking the status of the pool?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div><div class="h5"><div><div><div><div><p class="MsoNormal">
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">3) what pool statistics would mean?</p></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Aah, this is trickier. Again, maybe this only makes sense in the context of a specific listener, as well?  But yes, the problem of gathering aggregate statistics for a single pool spread across many back-ends becomes a lot more complicated.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><div><div class="h5"><div><div><div><div><p class="MsoNormal">
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">4) If the same pool is used on <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">To be able to preserve existing meaningful healthmonitors, members and statistics API we will need to create associations for everything, or just change API in backward incompatible way.<u></u><u></u></p>

</div>
<div>
<p class="MsoNormal">My opinion is that it make sense to limit such ability (reusing pools by vips deployed on different backends) in favor of simpler code, IMO it's really a big deal. Pool is lightweight enough to not to share it as an object.</p>
</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>Agreed--  not having re-usable pools just means the tenant needs to do more housekeeping in a larger environment.</div><div><br></div><div>Honestly...  even among our largest clients, we rarely see them re-using pools, or having pools associated with multiple listeners. So, this might be a moot point for the 90% use case anyway.</div>
<div><br></div><div>Thanks,</div><div>Stephen</div><div><br></div><div> </div></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807

</div></div>