<div dir="ltr">Small correction to my option #4 (here as #4.1). Neutron port_id should be an attribute of the 'loadbalancer' object, not the 'cluster' object. (Though cluster should have a network_id attribute).</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 6:28 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 y'all!<div><br></div><div>Eugene: Are the arrows in your diagrams meaningful?</div><div><br></div>
<div>Regarding existing workflows: Do we have any idea how widely the existing Neutron LBaaS is being deployed / used in the wild? (In our environment, we don't use it yet because it's not sophisticated enough for many of our customers' needs.) In other words, is breaking backward compatibility a huge concern? In our environment, obviously it's not.</div>
<div><br></div><div>I personally favor #3 as suggested, but again, I do doubt the need to have pools associated with a vip_id, or listener_id: That is, in larger clusters it may be advantageous to have a single pool that is referenced by several listeners and VIPs. If we keep the vip_id as an attribute of a pool (implying a pool can belong to only one vip), this isn't too bad-- you can duplicate the behavior by having multiple pools with the same actual member ips associated (though different member object instantiations, of course), and just make sure you update all of these "clone" pools whenever adding / removing members or changing healthmonitors, etc. It's certainly more housekeeping on the part of the application developer, though.</div>
<div><br></div><div>You mention in the notes that having the pools with a vip_id attribute solves a collocation problem. What is this specific collocation problem?</div><div><br></div><div>If we go with #3, I would keep IP address as an attribute of the VIP in this model.<br>
<br>As far as not having a 'loadbalancer' entity: Again, I think we're going to need something like this when we solve the HA or horizontal scalability problem. If we're going to break workflows with the introduction of L7 rules, then I would prefer to approach the model changes that will need to happen for HA and horizontal scalability sooner rather than later, so that we don't have to (potentially) contemplate yet another workflow-backward-compatibility model change.</div>
<div><br></div><div>Could you please describe what is the 'provider/flavor' attribute of the VIP being proposed?</div>
<div><br></div><div>Anyway, the devil is often in the details on this, so I've created a few graphs to illustrate my understanding on these things, and my proposal for alterations of the ideas you've described on the wiki pages above.</div>
<div><br></div><div>These graphs are:</div><div><br></div><div>#3 VIP-centric solution (full object view): This is the #3 proposal filled out with the L7 proposal as detailed here: <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/l7" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/l7</a> and the objects having to do with load balancing and all their attributes as currently exist in the havana database.</div>
<div><br></div><div>#3 VIP-centric solution (abridged view): Only those objects corresponding to the #3 graph with all their attributes as I understand Mark is proposing.</div><div><br></div><div>#3 VIP-centric solution (sbalukoff edit): My proposed change to the #3 graph. That is, IP address should be an attribute of the VIP, and pool doesn't need to care about which VIP(s) it's a part of (from what I can tell-- again, let me know what that 'collocation problem' is, eh).</div>
<div><br></div><div>While we're at it, though, I would like to propose option #4: This is a model that you could almost look at as a happy medium between #2 and #3, that allows application developers / tenants to develop automation for business needs around load balancer objects, helps separate operational concerns that cloud administrators need to worry about from application development concerns (ie. physical or virtual load balancers are hidden from tenants), and provides a model that works well with HA and auto-scale topologies.</div>
<div><br></div><div>As usual, I'm happy to provide the .dot files for any of the above graphs.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Thanks,</div><div>Stephen</div><div><br></div><div><br></div>
</div>
<div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Tue, Feb 18, 2014 at 11:34 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi folks,<div><br></div><div>Recently we were discussing LBaaS object model with Mark McClain in order to address several problems that we faced while approaching L7 rules and multiple vips per pool.</div>
<div>
<br></div><div>To cut long story short: with existing workflow and model it's impossible to use L7 rules, because</div><div>each pool being created is 'instance' object in itself, it defines another logical configuration and can't be attached to other existing configuration.</div>
<div>To address this problem, plus create a base for multiple vips per pool, the 'loadbalancer' object was introduced (see <a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance</a> ).</div>
<div>However this approach raised a concern of whether we want to let user to care about 'instance' object.</div><div><br></div><div>My personal opinion is that letting user to work with 'loadbalancer' entity is no big deal (and might be even useful for terminological clarity; Libra and AWS APIs have that) especially if existing simple workflow is preserved, so the 'loadbalancer' entity is only required when working with L7 or multiple vips per pool.</div>
<div><br></div><div>The alternative solution proposed by Mark is described here under #3:</div><div><a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion" target="_blank">https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion</a></div>
<div>In (3) the root object of the configuration is VIP, where all kinds of bindings are made (such as provider, agent, device, router). To address 'multiple vips' case another entity 'Listener' is introduced, which receives most attributes of former 'VIP' (attribute sets are not finalized on those pictures, so don't pay much attention)</div>
<div>If you take closer look at #2 and #3 proposals, you'll see that they are essentially similar, where in #3 the VIP object takes instance/loadbalancer role from #2.</div><div>Both #2 and #3 proposals make sense to me because they address both problems with L7 and multiple vips (or listeners)</div>
<div>My concern about #3 is that it redefines lots of workflow and API aspects and even if we manage to make transition to #3 in backward-compatible way, it will be more complex in terms of code/testing, then #2 (which is on review already and works).</div>
<div><br></div><div>The whole thing is important design decision, so please share your thoughts everyone.</div><div><br></div><div>Thanks,<br></div><div>Eugene.</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>