<br>Hi team,<div><br></div><div>Eugene, overall the strategy of slimming down what we're trying to accomplish in terms of scheduling in Grizzly makes sense. Some of these deeper level issues are good topics we can discuss at the Havana release summit in April. </div>
<div><br></div><div>My only bit of feedback is along similar lines as Avishay. I believe the current LbaaS work being done is focused on a "scheduling model" where there are one or more pools of available LB devices, a pool is selected based on service type, and then a device selected from the pool, and communicated with via a driver. This is certainly one viable model for LBaaS, and it definitely makes sense to have a plugin that implements this model to communicate with many different types of LB devices. But its also important that we don't "bake" this model into assumptions about how all LBaaS plugins should work. For example, some LBaaS plugins may not expose the ability for operators to define scheduling, so having a generic construct for all lbaas plugins where operators always specify a scheduling algorithm for each service type doesn't make sense (note: this might make sense as configuration for a particular lbaas plugin, just not as a general construct for all plugins). </div>
<div><br></div><div>This is similar to what makes me nervous when I hear discussion of generic constructs for managing individual load-balancing devices from an operator layer. This may be something that some plugins do, but others do not, and we need to make sure we do not make our service-wide or lbaas-wide constructs too specific to our first lbaas plugin implementation. </div>
<div><br></div><div>It sounds like we're taking very simple approaches to these for the initial lbaas implementation in Grizzly, which is the right step. Coding up a first service plugin design will flesh out many of the deeper issues we need to talk about at the Havana summit and help serve as a very concrete example of the challenges we need to tackle. The trick is just doing it in a way that does not overly constrain what we can do in the future. </div>
<div><br></div><div>Dan</div><div><br></div><div><br><div class="gmail_quote">On Sun, Jan 27, 2013 at 5:28 AM, Avishay Balderman <span dir="ltr"><<a href="mailto:AvishayB@radware.com" target="_blank">AvishayB@radware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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,<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">As discussed previously in the ML (by Samuel Bercovici). the scheduler should be part of the device and not global as can be seen in the attached picture.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The only global logic is the selection of the appropriate Driver based on service type/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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The device selection logic might be based on vendor specific logic which is not be relevant in a global scope.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In addition, the appropriate registration of the different devices as well as the provisioning logic is unique to each vendor.<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">As we (Radware) plan to manage the placement in the Driver, we will not be using any of the logic discussed.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Is there any reason prohibiting the scheduling logic to be used by the HA Proxy driver privately and not as a global logic?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If other vendors want to use the device scheduler for their implementation, they can utilize this class the is also provided for the HA proxy.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Moreover, such class could be placed in a shared directory (ex: LBaaS_utility) so that anyone who wishes to use it, could get it from there.<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">Thanks<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">Avishay</span> </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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"><u></u><u></u></span></p><div class="im">
<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>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<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> Tuesday, January 22, 2013 5:21 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> [openstack-dev] [Quantum][LBaaS] Scheduling & device management for LBaaS<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div><p class="MsoNormal">Hi folks,<u></u><u></u></p><div><div class="h5">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'd like to present blueprint <a href="https://blueprints.launchpad.net/quantum/+spec/quantum-service-scheduler" target="_blank">
https://blueprints.launchpad.net/quantum/+spec/quantum-service-scheduler</a> which I feel needs to be in grizzly.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">You can find more detailed description in specification page.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Initially we planned to have comprehensive device management as separate plugin with extension and complicated schedulers.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">However due to the lack of time and reviewer resources we desided to greatly reduce the scope of this work.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">So, currently the code on review ( <a href="https://review.openstack.org/#/c/20225/" target="_blank">
https://review.openstack.org/#/c/20225/</a> ) introduces the following:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">1) Configuration management for service schedulers, e.g. admin can configure particular scheduler for particular service type<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">2) Simplistic scheduler for lbaas:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - scheduling algorithm that randomly chooses a device from list of devices<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> - device manager that reads devices from predefined conf-file (suggestion from Salvatore)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I believe this is reasonable minimum that will allow to use LBaaS service at least with some convenience. <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">(In fact, I'd provide some more scheduling algorithms)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We have also started to integrate this code with code of <a href="https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-and-rpc" title="Agent-based Loadbalancer Plugin" target="_blank"><span style="font-size:9.0pt;font-family:"Tahoma","sans-serif";color:#0033aa;background:white">lbaas-agent-and-rpc</span></a> according
to the call sequence diagram:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="http://wiki.openstack.org/Quantum/LBaaS/Architecture/Scheduler" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Architecture/Scheduler</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">So we plan that this code will be base patch for <a href="https://blueprints.launchpad.net/quantum/+spec/lbaas-agent-and-rpc" title="Agent-based Loadbalancer Plugin" target="_blank"><span style="font-size:9.0pt;font-family:"Tahoma","sans-serif";color:#0033aa;background:white">lbaas-agent-and-rpc</span></a>.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Eugene.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">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><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>
</div>