<div dir="ltr">Hi Iwamoto,<div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><br>
</div>I agree with Samuel here.  I feel the logical model and other issues<br>
(implementation etc.) are mixed in the discussion.<br></blockquote><div> </div><div>A little bit. While ideally it's better to separate it, in my opinion we need to have some 'fair bit' of implementation details</div>
<div>
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.</div>
<div><br></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'm failing to understand why the current model is unfit for L7 rules.<br>
<br>
  - pools belonging to a L7 group should be created with the same<br>
    provider/flavor by a user<br>
  - pool scheduling can be delayed until it is bound to a vip to make<br>
    sure pools belonging to a L7 group are scheduled to one backend<br>
<br></blockquote><div>While that could be an option, It's not as easy as it seems.</div><div>We've discussed that back on HK summit but at that point decided that it's undesirable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
> I think grouping vips and pools is important part of logical model, even if<br>
> some users may not care about it.<br>
<br>
</div>One possibility is to provide an optional data structure to describe<br>
grouping of vips and pools, on top of the existing pool-vip model.<br></blockquote><div>That would be 'loadbalancer' approach, #2 in a wiki page.</div><div>So far we tend to introduce such grouping directly into vip-pool relationship.</div>
<div>I plan to explain that in more detail on the meeting.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><br></div>Yes, there's little benefit in sharing pools at cost of the<br>
complexity.<br></blockquote><div>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.</div><div><br></div><div>
Hope to see you on the meeting!</div><div><br></div><div>Thanks,</div><div>Eugene. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
--<br>
IWAMOTO Toshihiro<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div>