At Wed, 19 Feb 2014 20:23:04 +0400,
Eugene Nikanorov wrote:
>
> Hi Sam,
>
> My comments inline:
>
>
> On Wed, Feb 19, 2014 at 4:57 PM, Samuel Bercovici <[email protected]>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.
I agree with Samuel here. I feel the logical model and other issues
(implementation etc.) are mixed in the discussion.
I'm failing to understand why the current model is unfit for L7 rules.
- pools belonging to a L7 group should be created with the same
provider/flavor by a user
- pool scheduling can be delayed until it is bound to a vip to make
sure pools belonging to a L7 group are scheduled to one backend
I think proposed changes are introduction of "implementation details"
and as a general rule it's better to be hidden from users.
> 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$(D+"(Bdefault_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.
One possibility is to provide an optional data structure to describe
grouping of vips and pools, on top of the existing pool-vip model.
> > 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$(D)N+"(Bpool and
> > accordingly configure the backend that those vip$(D)N+"(Bpool 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$(D)N+"(Bpool
> > 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$(D)N+"(Bpool) should be
> > modified
> > with only vip pointing to a pool (vip$(D+"(Bpool) 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.
Yes, there's little benefit in sharing pools at cost of the
complexity.
--
IWAMOTO Toshihiro
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
