Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140218/f33420e9/attachment.html>