DistributedScheduler

• Launchpad Entry: NovaSpec:bexar-distributed-scheduler
• Created: 2010-11-16
• Contributors: Eric Day, Paul Voccio, Vish Ishaya

Summary

This was originally named 'distributed data store', but after design summit talks we've realized this would be best implemented as an optional scheduler. In order to accomplish this, the core needs to provide the appropriate API to be able to write such a scheduler. This means the scheduler using a distributed data store will most likely not be the default for simple installations, and instead something suitable for large scale deployments.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

There should be no visible changes to the end users, all this work will be behind the API servers.

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

Unresolved issues

None

BoF agenda and discussion

The two relevant sessions at the Bexar design summit had the following notes:

http://etherpad.openstack.org/DistributedDataStore http://etherpad.openstack.org/multicluster

---