[openstack-dev] [nova] versioning scheme for consumable libraries

Thierry Carrez thierry at openstack.org
Thu Nov 22 10:34:21 UTC 2012


Monty Taylor wrote:
> On 11/21/2012 09:13 AM, Doug Hellmann wrote:
> 
>>     My understanding of option 5 is that the library would be use by
>>     ceilometer to access Nova, not the other way around ?
>>
>> I thought that option represented moving the virtualization code out of
>> nova into a library that was used by both components for talking to the
>> hypervisor. That introduces a new dependency, but neither component is
>> communicating with the other so there is still no dependency between
>> nova and ceilometer (in fact, removing our current dependency on nova is
>> part of the motivation for these changes).
> 
> I'm a fan of this. It uses existing software engineering concepts
> (libraries) that are well understood with well understood machinery. Of
> course, the proof is in the pudding (what does the patch actually look
> like) - but I think this has the best chance of being something that
> doesn't turn crazy.

This just looks a lot like an Oslo (common code) library. Is there any
reason why we couldn't just use Oslo for this ? The code is common
between Nova and Ceilometer, and should become a separate library
(oslo-virt ?) used by both. That way we reuse a well-known model and
there is no reason to create a special case, and I'm completely fine
with it.

The versioning scheme discussion then becomes the same as the oslo
libraries versioning scheme discussion, and I suggest we continue there:

http://lists.openstack.org/pipermail/openstack-dev/2012-November/002709.html

Additional questions on the oslo route: is it OK to move to oslo, today,
code that is currently only used in one core project (Nova), to care for
the need of an incubated project (Ceilometer) ? Could we be using
oslo-incubator copy/update mechanism in the first stage of this ? I
guess we need markmc's view on this.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack



More information about the OpenStack-dev mailing list