Open Stack

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.

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".

debo


On Tue, Dec 3, 2013 at 9:58 AM, Russell Bryant <rbryant at redhat.com> wrote:

> On 12/03/2013 07:22 AM, Boris Pavlovic wrote:
> > Hi all,
> >
> >
> > Finally found a bit time to write my thoughts.
> >
> > There are few blockers that make really complex to build scheduler as a
> > services or even to move main part of scheduler code to separated lib.
> > We already have one unsuccessfully effort
> > https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler .
> >
> > Major problems that we faced were next:
> > 1) Hard connection with project db api layer (e.g. nova.db.api,
> > cinder.db.api)
> > 2) Hard connection between db.models and host_states
> > 3) Hardcoded host states objects structure
> > 4) There is no namespace support in host states (so we are not able to
> > keep all filters for all projects in the same place)
> > 5) Different API methods, that can't be effectively generalized.
> >
> >
> > Main goals of no-db-scheduler effort are:
> > 1) Make scheduling much faster, storing data locally on each scheduler
> > and just syncing states of them
> > 2) Remove connections between project.db.api and scheduler.db
> > 3) Make host_states just JSON like objects
> > 4) Add namespace support in host_states
> >
> > When this part will be finished, we will have actually only 1 problem
> > what to do with DB API methods, and business logic of each project. What
> > I see is that there are 2 different ways:
>
> If the new project is just a forklift of the existing code that still
> imports nova's db API and accesses Nova's DB, I don't think the initial
> forklift necessarily has to be blocked on completing no-db-scheduler.
> That can happen after just as easily (depending on which effort is ready
> first).
>
> > 1) Make scheduler as a big lib, then implement RPC methods + bit of
> > business logic in each project
> > 2) Move all RPC calls from nova,cinder,ironic,... and business logic in
> > 1 scheduler as a service
>
> Right now I think #2 is the approach we should take.  This is mainly
> because there is common information that is needed for the scheduling
> logic for resources in multiple projects.
>
> --
> Russell Bryant
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
-Debo~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131203/22f16bdf/attachment.html>