<div dir="ltr">Khanh-Toan, <div><br></div><div><p class="MsoNormal" style="font-family:'times new roman','new york',times,serif;font-size:16px"><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">>> There is a need for a scheduler that can scheduling a group of resources as a whole, which is difficult to realize due to the separation of Nova, Cinder –scheduler. Thus I’m in favor of a dedicated scheduler component.</span></p>
<div><br></div><div>What we need is to have one scheduler that is able effectively to store all data, </div></div><div><br></div><div><br></div><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">>> However, before talking about API or implementation, wouldn't it be better to see if the nova/cinder scheduler is independent enough to be separated from the core, in particular the data that the require to make a proper scheduling decision? It is reasonable to look again at the current architecture of Nova and Cinder to see which relation that</span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">  </span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">nova-scheduler and cinder-scheduler have with the rest of nova/cinder components, and which data they take from nova/cinder DB and whether these data can be separated from Nova/Cinder.</span><br>
</div><div><br></div><div><br></div><div>Before starting implementation of new scheduler we made this investigation..</div><div>Actually schedulers in nova and cinder are almost the same. And they are pretty separated from the core of projects: </div>
<div>1) They are separated services</div><div>2) Other services (e.g. compute api) already calls scheduler through rpc </div><div>3) Scheduler services call other services (e.g. compute manager) through rpc</div><div>4) Code base for scheduler service and other services are different (common parts are already mostly in oslo)</div>
<div><br></div><div>Only thing that is hard bind with scheduler is project DB.</div><div>But after switching to separated storage (e.g. memcached) scheduler won't depend on project db. </div><div><br></div><div><br></div>
<div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:15px">>> Is it really OK to drop these tables? Could Nova can work without them (e.g. rollback)? And if Ceilometer is about to ask nova for host state metrics ?</span><br>
</div><div><br></div><div>Yes it is OK, because now ceilometer and other projects could ask scheduler about host state. (I don't see any problems)</div><div><br></div><div><br></div><div><br></div><div>Alex, </div><div>
<br></div><div><tt><font>>> So, Cinder (as well as Neutron, and potentially others) would need to be hooked to Nova rpc?</font></tt><span style="font-family:arial,sans-serif;font-size:13px"> </span><br style="font-family:arial,sans-serif;font-size:13px">
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>As a first step, to prove approach yes, but I hope that we won't have "nova" or "cinder" scheduler at all. We will have just scheduler that works well. </div>
<div><br></div><div><br></div><div>>> <tt><font>I was referring to external (REST) APIs. E.g., to specify affinity.</font></tt><span style="font-size:13px;font-family:arial,sans-serif"> </span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Yes this should be moved as well to scheduler API..</span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><tt><font>>> Instances of memcached. In an environment with multiple schedulers. I think you mentioned that if we have, say, 10 schedulers, we will also have 10 instances of memcached.</font></tt><span style="font-family:arial,sans-serif;font-size:13px"> </span><br style="font-family:arial,sans-serif;font-size:13px">
</div><div><br></div><div><br></div><div>Actually we are going to make implementation based on sqlalchemy as well. In case of memcached I just say one of arch, that you could run on each server with scheduler service memcahced instance. But it is not required, you can have even just one memcached instance for all scheulers (but it is not HA).</div>
<div><br></div><div><br></div><div>Best regards,<br>Boris Pavlovic </div><div>---</div><div>Mirantis Inc. </div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Nov 17, 2013 at 9:27 PM, Alex Glikson <span dir="ltr"><<a href="mailto:GLIKSON@il.ibm.com" target="_blank">GLIKSON@il.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><tt><font>Boris Pavlovic <<a href="mailto:bpavlovic@mirantis.com" target="_blank">bpavlovic@mirantis.com</a>> wrote on
15/11/2013 05:57:20 PM:<div class="im"><br>
<br>
> >> How do you envision the life cycle of such a scheduler in
terms <br>
> of code repository, build, test, etc? </div></font></tt>
<br><div class="im"><tt><font>> <br>
> As a first step we could just make it inside nova, when we finish
<br>
> and prove that this approach works well we could split it out the
<br>
> nova in separated project and integrate with devstack and so on so
on...</font></tt>
<br>
<br></div><tt><font>So, Cinder (as well as Neutron, and potentially others)
would need to be hooked to Nova rpc?</font></tt>
<br><div class="im">
<br><tt><font>> >> What kind of changes to provisioning
APIs do you envision to <br>
> 'feed' such a scheduler? </font></tt>
<br><tt><font>> <br>
> At this moment nova.scheduler is already separated service with amqp<br>
> queue, what we need at this moment is to add 1 new rpc method to it.<br>
> That will update state of some host. </font></tt>
<br>
<br></div><tt><font>I was referring to external (REST) APIs. E.g., to
specify affinity.</font></tt>
<br><div class="im">
<br><tt><font>> >> Also, there are some interesting technical
challenges (e.g., <br>
> state management across potentially large number of instances of memcached). </font></tt>
<br><tt><font>> <br>
> 10-100k keys-values is nothing for memcached. So what kind of instances?</font></tt>
<br>
<br></div><tt><font>Instances of memcached. In an environment with multiple
schedulers. I think you mentioned that if we have, say, 10 schedulers,
we will also have 10 instances of memcached.</font></tt>
<br>
<br><tt><font>Regards,</font></tt>
<br><tt><font>Alex</font></tt>
<br><div class="HOEnZb"><div class="h5">
<br><tt><font>> Best regards,</font></tt>
<br><tt><font>> Boris Pavlovic</font></tt>
<br><tt><font>> <br>
> <br>
</font></tt>
<br><tt><font>> On Sun, Nov 10, 2013 at 4:20 PM, Alex Glikson
<<a href="mailto:GLIKSON@il.ibm.com" target="_blank">GLIKSON@il.ibm.com</a>> wrote:</font></tt>
<br><tt><font>> Hi Boris, <br>
> <br>
> This is a very interesting approach. <br>
> How do you envision the life cycle of such a scheduler in terms of
<br>
> code repository, build, test, etc? <br>
> What kind of changes to provisioning APIs do you envision to 'feed'
<br>
> such a scheduler? <br>
> Any particular reason you didn't mention Neutron? <br>
> Also, there are some interesting technical challenges (e.g., state
<br>
> management across potentially large number of instances of memcached).
<br>
> <br>
> Thanks, <br>
> Alex <br>
> <br>
> <br>
> Boris Pavlovic <<a href="mailto:bpavlovic@mirantis.com" target="_blank">bpavlovic@mirantis.com</a>> wrote on 10/11/2013
07:05:42 PM:<br>
> <br>
> > From: Boris Pavlovic <<a href="mailto:bpavlovic@mirantis.com" target="_blank">bpavlovic@mirantis.com</a>> <br>
> > To: "OpenStack Development Mailing List (not for usage questions)"
<br>
> > <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, <br>
> > Date: 10/11/2013 07:07 PM <br>
> > Subject: Re: [openstack-dev] [nova][cinder][oslo][scheduler]
How to <br>
> > leverage oslo schduler/filters for nova and cinder </font></tt>
<br><tt><font>> > <br>
> > Jay,  <br>
> > <br>
> > Hi Jay, yes we were working about putting all common stuff in
oslo-<br>
> > scheduler. (not only filters) <br>
> > <br>
> > As a result of this work we understood, that this is wrong approach.<br>
> > Because it makes result code very complex and unclear. And actually
<br>
> > we didn't find the way to put all common stuff inside oslo. Instead
<br>
> > of trying to make life too complex we found better approach.
<br>
> >  Implement scheduler aaS that can scale (current solution
has some <br>
> > scale issues) & store all data from nova, cinder & probably
other places. <br>
> > <br>
> > To implement such approach we should change a bit current architecture: 
<br>
> > 1) Scheduler should store all his data (not nova.db & cinder.db)
<br>
> > 2) Scheduler should always have own snapshot of "wold"
state, and <br>
> > sync it with another schedulers using something that is quite
fast <br>
> > (e.g. memcached)  <br>
> > 3) Merge schedulers rpc methods from nova & cinder in one
scheduler <br>
> > (it is possbile if we store all data from cinder & nova in
one sceduler).  <br>
> > 4) Drop cinder, and nova tables that store host states (as we
don't <br>
> > need them)  <br>
> > <br>
> > We implemented already base start (mechanism that store snapshot
of <br>
> > world state & sync it between different schedulers): 
<br>
> > <br>
> > </font></tt><a href="https://review.openstack.org/#/c/45867/" target="_blank"><tt><font>https://review.openstack.org/#/c/45867/</font></tt></a><tt><font>
(it is still bit in WIP) <br>
> > <br>
> > Best regards,  <br>
> > Boris Pavlovic <br>
> > --- <br>
> > Mirantis Inc.  <br>
> > <br>
> > <br>
> <br>
> > On Sun, Nov 10, 2013 at 1:59 PM, Jay Lau <<a href="mailto:jay.lau.513@gmail.com" target="_blank">jay.lau.513@gmail.com</a>>
wrote: <br>
> > I noticed that there is already a bp in oslo tracing what I want
to do: <br>
> > </font></tt><a href="https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler" target="_blank"><tt><font>https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler</font></tt></a><tt><font><br>
> <br>
> > Thanks,<br>
> <br>
> > Jay<br>
> <br>
> > <br>
> <br>
> > 2013/11/9 Jay Lau <<a href="mailto:jay.lau.513@gmail.com" target="_blank">jay.lau.513@gmail.com</a>> <br>
> > Greetings, <br>
> > <br>
> > Now in oslo, we already put some scheduler filters/weights logic
<br>
> > there and cinder is using oslo scheduler filters/weights logic,
<br>
> > seems we want both nova&cinder use this logic in future.
<br>
> > <br>
> > Found some problems as following: <br>
> > 1) In cinder, some filters/weight logic reside in cinder/openstack/<br>
> > common/scheduler and some filter/weight logic in cinder/scheduler,
<br>
> > this is not consistent and also will make some cinder hackers
<br>
> > confused: where shall I put the scheduler filter/weight. <br>
> > 2) Nova is not using filter/weight from oslo and also not using
<br>
> > entry point to handle all filter/weight. <br>
> > 3) There is not enough filters in oslo, we may need to add more
<br>
> > there: such as same host filter, different host filter, retry
filter etc. <br>
> > <br>
> > So my proposal is as following: <br>
> > 1) Add more filters to oslo, such as same host filter, different
<br>
> > host filter, retry filter etc. <br>
> > 2) Move all filters/weight logic in cinder from cinder/scheduler
to <br>
> > cinder/openstack/common/scheduler <br>
> > 3) Enable nova use filter/weight logic from oslo (Move all filter
<br>
> > logic to nova/openstack/common/scheduler) and also use entry
point <br>
> > to handle all filters/weight logic. <br>
> > <br>
> > Comments? <br>
> > <br>
> > Thanks, <br>
> > <br>
> > Jay <br>
> > <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>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font><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>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a>
<br><tt><font>> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font><br>
</font></tt>
<br><tt><font>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font><br>
</font></tt></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></div>