Hi, Sam,<div><br></div><div>Driver API is available on wiki <a href="http://wiki.openstack.org/Quantum/LBaaS/DriverAPI">http://wiki.openstack.org/Quantum/LBaaS/DriverAPI</a> for a couple of weeks.</div><div><br></div><div>
Regarding different use cases: they're certainly a must have, but considering time remaining to g-3, it's highly unlikely that anything new will be implemented, reviewed and merged.</div><div><br></div><div>Thanks,</div>
<div>Eugene.<br><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div><div class="h5">On Sun, Jan 27, 2013 at 6:50 PM, Samuel Bercovici <span dir="ltr"><<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">






<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Eugene,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">My comments bellow.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">               -Sam.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eugene Nikanorov [mailto:<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>]
<br>
<b>Sent:</b> Friday, January 25, 2013 10:29 PM</span></p><div><br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> [openstack-dev] [Quantum][LBaaS] Default insertion mode for balancer device<u></u><u></u></div><p></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Hi folks,<u></u><u></u></p><div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Currently we're working on integrating together parts of LBaaS which will allow the whole service to work. <u></u><u></u></p>
</div>
</div><div><div>
<p class="MsoNormal">As you know, the only driver that is under development now is HAProxy driver.<u></u><u></u></p>
</div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Sam> We (Radware) are waiting for the Driver API to be available so we can complete our support for grizzly.<u></u><u></u></span></p>


</div><div>
<div>
<p class="MsoNormal">Also, It seems to be the only type of balancer going into grizzly.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal">We faced a certain problem with that: it seems that the most viable use case for HAProxy loadbalancer is private loadbalancer which is brought up by a tenant in a private network (E.g. balancer is in the same L2 domain with the pool members). <u></u><u></u></p>


</div>
<div>
<p class="MsoNormal">Then it is configured via LBaaS service and then tenant may assign floating IP to the balancer device making possible to access its VMs from internet through the balancer.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">However it became obvious that this use case is incompatible with our simplified device management based on configuration file.<u></u><u></u></p>
</div>
</div><div><div>
<p class="MsoNormal">Configuration file implies that it is edited by admin and modification requires quantum restart. E.g. tenant can't add it's private device, etc.<u></u><u></u></p>
</div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Sam> The alternative is a two legged approach so that the LB service is connecting between the private network and the other network and the VIP does not sit
 behind a floating IP. We might want to consider using the floating IP as the VIP address.<u></u><u></u></span></p>
</div><div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If we go with conf-based device management, defining HAProxy to be shared device, we will need some additional configuration of machine with HAProxy to have connectivity with certain tenant network, possibly having OVS on it, etc. <u></u><u></u></p>


</div>
<div>
<p class="MsoNormal">Also, pool members from different tenants having subnets with the same IP ranges are indistinguishable from HAProxy conf-file perspective.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Solving any of mentioned problems with shared HAProxy seems to take some time to implement, test and review and obviously that will miss grizzly.<u></u><u></u></p>
</div>
</div><div>
<p class="MsoNormal"><span style="color:#1f497d">Sam>I agree that to solve this challenge (or also the other topology in which HA Proxy is connected to the 2^nd network), it would be easier for HA Proxy to be assigned per network/tenant and not be
 shared.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</div><div>
<div>
<p class="MsoNormal">So currently we're thinking again about having device management as a plugin with it's extension, to focus "private devices" use case.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">We have already written the code a while ago, but then went with simpler conf-based approach. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I'd estimate we could get device management plugin code on gerrit in a week from now, which will give ~2 weeks of time for review plus a week till g-3<u></u><u></u></p>
</div>
</div><div>
<p class="MsoNormal"><span style="color:#1f497d">Sam>As with the proposed scheduler, this should be done as part of the HA Proxy Device. It makes sense to have an HA proxy Device Management capabilities.<u></u><u></u></span></p>


<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</div><div>
<div>
<p class="MsoNormal">We'd like to hear your opinion:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">1) Is the mentioned use case of private HAProxy the one we should focus on for G-3? <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If not, then please describe alternatives.<u></u><u></u></p>
</div>
</div><div>
<p class="MsoNormal"><span style="color:#1f497d">Sam> I think there are two primary use cases. The first is a public/private network in which a pool of HA Proxies provide service to such a network.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">Sam> The second is the one discussed above either one legged + fixed IP or two legged using the fixed IP as VIP.</span><u></u><u></u></p>
</div><div>
<div>
<p class="MsoNormal">I'd like to emphasize that this use case goes inline with our future plans to make automatic provisioning of private tenant HAProxies via Nova.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal">2) Do you think it's ok to go further with dev management plugin? We need it to provide tenants ability to add their private devices.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">If you feel that we don't have enough time for that, please advise alternative.<u></u><u></u></p>
</div>
</div><div>
<p class="MsoNormal"><span style="color:#1f497d">Sam> This looks like reasonable if implemented for the HA Proxy Device Driver and exposed as utility classes to anyone who want to use it.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">Sam> This should also be done after APIs for Driver and Driver selection are available ASAP so that vendors who wishes to start integration could do so.<u></u><u></u></span></p>


<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Eugene.<u></u><u></u></p>
</div>
</div>
</div>

<br></div></div>_______________________________________________<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>
<br></blockquote></div><br></div>
</blockquote></div><br></div>