Open Stack

Hi guys,

I have been catching up on this interesting thread around the object model, so sorry in advance to jump in late in this debate, and if I missed some of the subtleties of the points being made so far.

I tend to agree with Sam that the original intention of the current object model was never tied to a physical deployment. We seem to be confusing the tenant-facing object model which is completely logical (albeit with some "properties" or "qualities" that a tenant can express) from the deployment/implementation aspects of such a logical model (things like cluster/HA, one vs. multiple backends, virtual appliance vs. OS process, etc). We discussed in the past, the need for an Admin API (separate from the tenant API) where a cloud administrator (as opposed to a tenant) could manage the deployment aspects, and could construct different offerings that can be exposed to a tenant, but in the absence of such as admin API (which would necessarily be very technology-specific), this responsibility is currently shouldered by the drivers.

IMO a tenant should only care about whether VIPs/Pools are grouped together to the extent that the provider allows the tenant to express such a preference. Some providers will allow their tenants to express such a preference (e.g. because it might impact cost), and others might not as it wouldn't make sense in their implementation.

Also the mapping between pool and backend is not necessarily 1:1, and is not necessarily at the creation time of pool, as this is purely a driver implementation decision (I know that currently implementations are like this, but another driver can choose a different approach). A driver could for example delay mapping a pool to a backend, until a full LB configuration is completed (when pool has members, and a VIP is attached to the pool). A driver can also move these resources around between backends, if it finds out, it put them in a non-optimal backend initially. As long as the logical model is realized and remains consistent from the tenant point of view, implementations should be free to achieve that goal in any way they see fit.

Youcef

From: Eugene Nikanorov [mailto:enikanorov at mirantis.com]
Sent: Wednesday, February 19, 2014 8:23 AM
To: Samuel Bercovici
Cc: OpenStack Development Mailing List; Mark McClain; Salvatore Orlando; sbalukoff at bluebox.net; Youcef Laribi; Avishay Balderman
Subject: Re: [Neutron][LBaaS] Object Model discussion

Hi Sam,

My comments inline:

On Wed, Feb 19, 2014 at 4:57 PM, Samuel Bercovici <SamuelB at radware.com<mailto: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/2546e7c1/attachment.html>