[openstack-dev] [Neutron][LBaaS] Object Model discussion

Eugene Nikanorov enikanorov at mirantis.com
Wed Feb 19 16:23:04 UTC 2014


Hi Sam,

My comments inline:


On Wed, Feb 19, 2014 at 4:57 PM, Samuel Bercovici <SamuelB at radware.com>wrote:

>  Hi,
>
>
>
> I think we mix different aspects of operations. And try to solve a non
> "problem".
>
Not really, Advanced features we're trying to introduce are incompatible by
both object model and API.

 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.
>
That's correct. Tenant may or may not care about how it is grouped on the
backend. We need to support both cases.

>  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.
>
I think grouping vips and pools is important part of logical model, even if
some users may not care about it.


> 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.
>
 That's not how it currently works - that's why we're trying to address it.
Having pool shareable between backends at least requires to move 'instance'
role from the pool to some other entity, and also that changes a number of
API aspects.

 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.
>
So proposal tries to address 2 issues:
1) in many cases it is desirable to know about grouping of logical objects
on the backend
2) currently physical model implied when working with pools, because pool
is the root and corresponds to backend with 1:1 mapping


>
> 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.
>
Reusing pools by vips is not as simple as it seems.
If those vips belong to 1 backend (that by itself requires tenant to know
about that) - that's no problem, but if they don't, then:
1) what 'status' attribute of the pool would mean?
2) how health monitors for the pool will be deployed? and what their
statuses would mean?
3) what pool statistics would mean?
4) If the same pool is used on

To be able to preserve existing meaningful healthmonitors, members and
statistics API we will need to create associations for everything, or just
change API in backward incompatible way.
My opinion is that it make sense to limit such ability (reusing pools by
vips deployed on different backends) in favor of simpler code, IMO it's
really a big deal. Pool is lightweight enough to not to share it as an
object.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140219/2cc87915/attachment.html>


More information about the OpenStack-dev mailing list