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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev