Open Stack

Hi,

I think we mix different aspects of operations. And try to solve a non "problem".

>From APIs/Operations we are mixing the following models:

1.       Logical model (which as far as I understand is the topic of this discussion) - tenants define what they need logically vip-->default_pool, l7 association, ssl, etc.

2.       Physical model - operator / vendor install and specify how backend gets implemented.

3.       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.

Another "problem", which all the new proposals are trying to solve, is placing a pools which can be a root/default for a vip <---->pool relationship also as part association with l7 policy of another vip<---->pool that is configured in another backend.
I think this is not a "problem".
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<---->pool and accordingly configure the backend that those vip<---->pool are deployed on.
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<---->pool pair can be instantiated into some back end.
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.

I think that the current logical model is fine with the exception that the two way reference between vip and pool (vip<---->pool) should be modified with only vip pointing to a pool (vip-->pool) which allows reusing the pool with multiple vips. This also means that all those vips will be placed on the same place as the pool they are pointing to as their default pool.

Regards,
                -Sam.





From: Eugene Nikanorov [mailto:enikanorov at mirantis.com]
Sent: Tuesday, February 18, 2014 9:35 PM
To: OpenStack Development Mailing List
Cc: Youcef Laribi; Samuel Bercovici; sbalukoff at bluebox.net; Mark McClain; Salvatore Orlando
Subject: [Neutron][LBaaS] Object Model discussion

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/20140219/2379fa04/attachment.html>