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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev