Open Stack

Hi y'all!

Eugene:  Are the arrows in your diagrams meaningful?

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.

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.

You mention in the notes that having the pools with a vip_id attribute
solves a collocation problem. What is this specific collocation problem?

If we go with #3, I would keep IP address as an attribute of the VIP in
this model.

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.

Could you please describe what is the 'provider/flavor' attribute of the
VIP being proposed?

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.

These graphs are:

#3 VIP-centric solution (full object view):  This is the #3 proposal filled
out with the L7 proposal as detailed here:
https://wiki.openstack.org/wiki/Neutron/LBaaS/l7 and the objects having to
do with load balancing and all their attributes as currently exist in the
havana database.

#3 VIP-centric solution (abridged view): Only those objects corresponding
to the #3 graph with all their attributes as I understand Mark is proposing.

#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).

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.

As usual, I'm happy to provide the .dot files for any of the above graphs.

Thoughts?

Thanks,
Stephen




On Tue, Feb 18, 2014 at 11:34 AM, Eugene Nikanorov
<enikanorov at mirantis.com>wrote:

> Hi folks,
>
> 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.
>
> To cut long story short: with existing workflow and model it's impossible
> to use L7 rules, because
> each pool being created is 'instance' object in itself, it defines another
> logical configuration and can't be attached to other existing configuration.
> To address this problem, plus create a base for multiple vips per pool,
> the 'loadbalancer' object was introduced (see
> https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance ).
> However this approach raised a concern of whether we want to let user to
> care about 'instance' object.
>
> 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.
>
> The alternative solution proposed by Mark is described here under #3:
>
> https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance/Discussion
> 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)
> 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.
> Both #2 and #3 proposals make sense to me because they address both
> problems with L7 and multiple vips (or listeners)
> 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).
>
> The whole thing is important design decision, so please share your
> thoughts everyone.
>
> Thanks,
> Eugene.
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/1ef40d68/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: number-3-full.png
Type: image/png
Size: 120879 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/1ef40d68/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: number-3-abridged.png
Type: image/png
Size: 72880 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/1ef40d68/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: number-3-sbalukoff.png
Type: image/png
Size: 61252 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/1ef40d68/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: number-4-sbalukoff.png
Type: image/png
Size: 88895 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/1ef40d68/attachment-0007.png>