Open Stack

On 12/02/2013 03:31 PM, Vishvananda Ishaya wrote:
> 
> On Dec 2, 2013, at 9:12 AM, Russell Bryant <rbryant at redhat.com>
> wrote:
> 
>> On 12/02/2013 10:59 AM, Gary Kotton wrote:
>>> I think that this is certainly different. It is something that
>>> we we want and need a user facing API. Examples: - aggregates -
>>> per host scheduling - instance groups
>>> 
>>> Etc.
>>> 
>>> That is just taking the nova options into account and not the
>>> other modules. How doul one configure that we would like to
>>> have storage proximity for a VM? This is where things start to
>>> get very interesting and enable the cross service scheduling
>>> (which is the goal of this no?).
>> 
>> An explicit part of this plan is that all of the things you're
>> talking about are *not* in scope until the forklift is complete
>> and the new thing is a functional replacement for the existing
>> nova-scheduler.  We want to get the project established and going
>> so that it is a place where this work can take place.  We do
>> *not* want to slow down the work of getting the project
>> established by making these things a prerequisite.
> 
> 
> I'm all for the forklift approach since I don't think we will make
> any progress if we stall going back into REST api design.
> 
> I'm going to reopen a can of worms, though. I think the most
> difficult part of the forklift will be moving stuff out of the
> existing databases into a new database. We had to deal with this in
> cinder and having a db export and import strategy is annoying to
> say the least. Managing the db-related code was the majority of the
> work during the cinder split.
> 
> I think this forklift will be way easier if we merge the
> no-db-scheduler[1] patches first before separating the scheduler
> out into its own project:
> 
> https://blueprints.launchpad.net/nova/+spec/no-db-scheduler
> 
> I think the effort to get this finished is smaller than the effort
> to write db migrations and syncing scripts for the new project.

Agreed that this should make it easier.

My thought was that the split out scheduler could just import nova's
db API and use it against nova's database directly until this work
gets done.  If the forklift goes that route instead of any sort of
work to migrate data from one db to another, they could really happen
in any order, I think.

-- 
Russell Bryant