Open Stack

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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140220/d525d33b/attachment.html>