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:enikano...@mirantis.com]
Sent: Tuesday, February 18, 2014 9:35 PM
To: OpenStack Development Mailing List
Cc: Youcef Laribi; Samuel Bercovici; sbaluk...@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
