Open Stack

On Dec 2, 2013, at 12:38 PM, Russell Bryant <rbryant at redhat.com> wrote:

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


That is a good point. If the forklift is still talking to nova's db
then it would be significantly less duplication and i could see doing
it in the reverse order. The no-db-stuff should be done before trying
to implement cinder support so we don't have the messiness of the
scheduler talking to multiple db apis.

Vish

> 
> -- 
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131202/6615fc82/attachment.pgp>