<div>Hi Youcef,</div><div><br></div>Please see my comments inline:<br><br><div class="gmail_quote">On Thu, Dec 6, 2012 at 11:58 PM, Youcef Laribi <span dir="ltr"><<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.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 Eugene,<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"><a name="13b71ce7d3bb7f34__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">  </span>1) We may think of scheduler as a just a part of device management plugin since it is nothing more than an algorithm working on device list.<u></u><u></u></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p></div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This is why I want the confusion to be clarified. In your proposal, you had a scheduler per “service type”. This implies that the scheduler is not for LBaaS specific, it is common to all Service Plugins, so it cannot live in the LBaaS plugin.</span></p>
</div></div></blockquote><div>The most basic requirement for the whole scheduling component is configurability. </div><div>If we could write some scheduling algorithm in service type-agnostic way, then we may configure it to schedule resources of several service types. </div>
<div>But such algorithm still has to be specified for each service type.</div><div>Example1:</div><div>[LBaaS]</div><div>scheduler=quantum.plugins.common.scheduler.ChanceScheduler</div><div>[..aaS]</div><div>scheduler=quantum.plugins.common.scheduler.ChanceScheduler</div>
<div>Example2:</div><div><div>Example1:</div><div>[LBaaS]</div><div>scheduler=quantum.plugins.lbaas.scheduler.LBspecificScheduler</div><div>[..aaS]</div><div>scheduler=quantum.plugins.common.scheduler.ChanceScheduler</div>
</div><div><br></div><div>So for simplicity we can just think that we will have LBaaS-specific scheduling algorithms.</div><div><br></div><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><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">I also don’t want us to confuse the scheduler with device management. They may share the same database, but they have different functions in the system.</span></p>
</div></div></blockquote><div>You're right. So lets define scheduler framework to be the following:</div><div>1) Infrastructure allowing to configure scheduling algorithm for service type</div><div>2) Scheduling algorithms and their Adv Svc Plugins-facing interface</div>
<div>3) Code that interacts with device management plugin to retrieve device list and make association of form (device, resource)</div><div><br></div><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"><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">2) We probably doesn't need separate "device agent" component and process. Any kind of device-specific task may be handled by common "advanced service agent" which routes messages from Adv Svc Plugins and Device Management Plugin to corresponding device-specific code.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p></div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">That is the type of reaction I was expecting by drawing the diagram </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> I agree with you that all device-specific code should be in the driver, but I’m not sure about having an “advanced service agent” routing to LBaaS plugin then to the LBaaS agent. But these are minor details we can discuss later.<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">So, let’s first start clarifying the “service type” role. I think there is a lot of confusion here. Can we start sketching an API and payloads for creating them?</span></p>
</div></blockquote><div><div>Actually, before doing that I'd like to see Salvatore's "service types and service definitions" work. We need to see how it sticks together with what we're discussing. </div>
</div><div><br></div><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"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">By the way, I thought that Salvatore was responsible for driving “service type” management, so I want to hear from him more on this, or whoever is now driving this piece.</span></p>
</div></blockquote><div>That's right, although I think the scope of Salvatore's work is more close to some service-level configuration API and infrastructure as well as service insertion modes and doesn't include neither device management nor scheduling.</div>
<div><br></div><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"><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">Thanks<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Youcef<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> </span></p>
</div></blockquote><div>Thanks,</div><div>Eugene. </div><div> </div><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"><p class="MsoNormal">
</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> Thursday, December 6, 2012 11:05 AM</span></p><div class="im"><br><b>To:</b> OpenStack Development Mailing List<br><b>Subject:</b> Re: [openstack-dev] [Openstack-dev][Quantum][LBaaS] Quantum components needed for the LBaaS service<u></u><u></u></div>
<p></p><span class="HOEnZb"><font color="#888888"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Youcef,<u></u><u></u></p></font></span><div><div class="h5"><div><p class="MsoNormal"><u></u> <u></u></p></div>
<div><p class="MsoNormal">Thanks for the diagram, it quite close to what we are proposing.<u></u><u></u></p></div><div><p class="MsoNormal">A couple of additional notes:<u></u><u></u></p></div><div><p class="MsoNormal">1) We may think of scheduler as a just a part of device management plugin since it is nothing more than an algorithm working on device list.<u></u><u></u></p>
</div><div><p class="MsoNormal">2) We probably doesn't need separate "device agent" component and process. Any kind of device-specific task may be handled by common "advanced service agent" which routes messages from Adv Svc Plugins and Device Management Plugin to corresponding device-specific code.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">You may also look at workflow of pool creation operation as well as component 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"><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>
<p class="MsoNormal">On Thu, Dec 6, 2012 at 8:25 PM, John Gruber <<a href="mailto:john.t.gruber@gmail.com" target="_blank">john.t.gruber@gmail.com</a>> wrote:<u></u><u></u></p><p class="MsoNormal">Youcef,<u></u><u></u></p>
<div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thank you for the block diagram. I had a couple of questions:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">
>From your drawing, can I infer that the scheduler is to be provided as a python module and class and not a proper service interface? The decoupling through queue seems to be one of synchronous / asynchronous task scaling only. Why not a scheduler queue as well to allow the vendor line to be completely handled through AMQP messaging? The LBaaS vendor could create as simple or as complex a management system to interact with LBaaS through messaging. What are your thought about forcing the schedule coupling?<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Is it safe to say that the other issues of thorny coupling you are worried about can be isolated to discrete functional areas where proper interface definitions and RPC could avoid them?  <u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I agree with you BTW.  I've been writing some 'glue' for a project and finding other areas in Quantum itself which are too tightly tied to the data model of VM interfaces and it created a few thorns. It was a time consuming exercise to make Quantum functionality live behind an interface which would work simply through other vendor's interfaces as well. <u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">This is our trade-off of time vs complexity I know... <u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">
John<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p><div><div><div><p class="MsoNormal">On Wed, Dec 5, 2012 at 5:01 PM, Youcef Laribi <<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>> wrote:<u></u><u></u></p>
</div></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><div><div><p class="MsoNormal">The discussion on scheduling has prompted me to think that there are several inter-linked components that we have so far not discussed in detail, and I’m worried that diving into implementation without understanding how the different components will eventually fit together will create us problems later on. For example, we haven’t so far discussed the APIs for “service type” management (and this is creating confusion in other thread discussions), or for device management, as these have impact on the LBaaS piece. We need to understand the big picture of the components that will be in place, their dependencies, and the vendor-specific pieces and where they would be located.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">To start this discussion I have drawn an initial picture with the components that I think would need to be in place. So let’s start discussing the need for each component, its functions, where does it live (is it a Quantum plugin? is it something else?), what are the dependencies on the other components (in terms of interactions or DB sharing). The component diagram is here: <a href="http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+Services+components.png" target="_blank">http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+Services+components.png</a><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">I want us to discuss this in a little bit more detail, before we get too much into implementation and realize the thorny issues later on. <u></u><u></u></p><p class="MsoNormal">
 <u></u><u></u></p><p class="MsoNormal">Thanks<u></u><u></u></p><p class="MsoNormal"><span style="color:#888888">Youcef<u></u><u></u></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal" style="margin-bottom:12.0pt">
_______________________________________________<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><u></u><u></u></p>
</blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal" style="margin-bottom:12.0pt"><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><u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p>
</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>