[openstack-dev] [Nova][Scheduler] Will the Scheuler use Nova Objects?

Sylvain Bauza sylvain.bauza at gmail.com
Thu Jan 30 14:05:06 UTC 2014


2014-01-30 Andrew Laski <andrew.laski at rackspace.com>:

> On 01/30/14 at 04:13am, Gary Kotton wrote:
>
>> Hi,
>> I started to do the work - https://review.openstack.org/#/c/65691/. From
>> the comments on the review it did not seem the right way to go. So I gave
>> up on it. Sorry to not have updated. I personally think that the scheduler
>> should use objects, the reason for this is as follows:
>>
>> 1.  One of the aims of the objects is to enable seamless upgrades. If we
>> have this in the gannet, that starts with using only the nova database then
>> we can upgrade to using another database. The object interface will do the
>> translations
>> 2.  We may be able to leverage objects to interface with different types
>> of services. That will enable us to provide cross service features far
>> quicker.
>>
>
> I'm of the opinion that the scheduler should use objects, for all the
> reasons that Nova uses objects, but that they should not be Nova objects.
>  Ultimately what the scheduler needs is a concept of capacity, allocations,
> and locality of resources.  But the way those are modeled doesn't need to
> be tied to how Nova does it, and once the scope expands to include Cinder
> it may quickly turn out to be limiting to hold onto Nova objects.
>


I can't agree more. Gantt should use its own objects, and sync them with
Nova thanks to the Nova API (and novaclient bindings). If we consider Gantt
using Nova objects directly, it will result in having a big dependency with
Nova on requirements.txt which would be hard to deal with.

All that means we need to define what are Gantt objects (enough flexible
for adding other objects later on) and how Gantt should manage the
synchronization in between its models and Nova ones.

Thanks,
-Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140130/161ca420/attachment.html>


More information about the OpenStack-dev mailing list