<div dir="ltr">I agree with RussellB on this … if the forklift's goal is to just separate the scheduler, there should be no new features etc till the forklift is done and it should work as is with very minor config changes. <div>
<br></div><div>A scheduler has several features like place resources correctly, for example. Ideally, this should be a simple service that can allocate any resources to any available bucket - balls in bins, VMs in host, blocks/blobs on disk/SSD etc. Maybe the scheduler should operate on meta level resource maps for each "type" and delegate the precise decisions to the allocator for that "type". </div>
<div><br></div><div>debo </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 3, 2013 at 9:58 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/03/2013 07:22 AM, Boris Pavlovic wrote:<br>
> Hi all,<br>
><br>
><br>
> Finally found a bit time to write my thoughts.<br>
><br>
> There are few blockers that make really complex to build scheduler as a<br>
> services or even to move main part of scheduler code to separated lib.<br>
> We already have one unsuccessfully effort<br>
> <a href="https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler" target="_blank">https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler</a> .<br>
><br>
> Major problems that we faced were next:<br>
> 1) Hard connection with project db api layer (e.g. nova.db.api,<br>
> cinder.db.api)<br>
> 2) Hard connection between db.models and host_states<br>
> 3) Hardcoded host states objects structure<br>
> 4) There is no namespace support in host states (so we are not able to<br>
> keep all filters for all projects in the same place)<br>
> 5) Different API methods, that can't be effectively generalized.<br>
><br>
><br>
> Main goals of no-db-scheduler effort are:<br>
> 1) Make scheduling much faster, storing data locally on each scheduler<br>
> and just syncing states of them<br>
> 2) Remove connections between project.db.api and scheduler.db<br>
> 3) Make host_states just JSON like objects<br>
> 4) Add namespace support in host_states<br>
><br>
> When this part will be finished, we will have actually only 1 problem<br>
> what to do with DB API methods, and business logic of each project. What<br>
> I see is that there are 2 different ways:<br>
<br>
</div>If the new project is just a forklift of the existing code that still<br>
imports nova's db API and accesses Nova's DB, I don't think the initial<br>
forklift necessarily has to be blocked on completing no-db-scheduler.<br>
That can happen after just as easily (depending on which effort is ready<br>
first).<br>
<div class="im"><br>
> 1) Make scheduler as a big lib, then implement RPC methods + bit of<br>
> business logic in each project<br>
> 2) Move all RPC calls from nova,cinder,ironic,... and business logic in<br>
> 1 scheduler as a service<br>
<br>
</div>Right now I think #2 is the approach we should take.  This is mainly<br>
because there is common information that is needed for the scheduling<br>
logic for resources in multiple projects.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>-Debo~<br>
</div>