Open Stack

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

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

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ßà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.

Yes, there's little benefit in sharing pools at cost of the
complexity.

--
IWAMOTO Toshihiro