Open Stack

At Thu, 20 Feb 2014 15:21:49 +0400,
Eugene Nikanorov wrote:
> 
> Hi Iwamoto,
> 
> 
> > I agree with Samuel here.  I feel the logical model and other issues
> > (implementation etc.) are mixed in the discussion.
> >
> 
> A little bit. While ideally it's better to separate it, in my opinion we
> need to have some 'fair bit' of implementation details
> in API in order to reduce code complexity (I'll try to explain it on the
> meeting). Currently these 'implementation details' are implied because we
> deal with simplest configurations which maps 1:1 to a backend.

Exposing some implementation details as API might not be ideal but
would be accepable if it saves a lot of code complexity.

> > 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
> >
> > While that could be an option, It's not as easy as it seems.
> We've discussed that back on HK summit but at that point decided that it's
> undesirable.

Could you give some more details/examples why my proposal above is
undesirable?
In my opinion, pool rescheduling happens anyway when an agent dies,
and calculating pool-vip grouping based on their connectivity is not hard.


> > > 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.
> >
> That would be 'loadbalancer' approach, #2 in a wiki page.
> So far we tend to introduce such grouping directly into vip-pool
> relationship.
> I plan to explain that in more detail on the meeting.

My idea was to keep the 'loadbalancer' API optional for users who
don't care about grouping.

--
IWAMOTO Toshihiro