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. > 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. > > 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. > Yes, there's little benefit in sharing pools at cost of the > complexity. > Right, that's the suggestion, but such ability is also a consequence of pure logical config where backend considerations are not taken into account in the API. Hope to see you on the meeting! Thanks, Eugene. > > -- > IWAMOTO Toshihiro > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
