Open Stack

Eoghan Glynn wrote:
> I just want to scare up some ideas on what the versioning scheme
> should look like for the nova virt library discussed previously[1]
> (primarily for ceilometer use).

I'm a bit confused by what you exactly mean by "nova packages a
consumable library". Would that just be a Python Nova module that
ceilometer agents would import ? Or a separate client library that would
result in a different binary package ?

In particular, where would that library code live ? In Nova tree ? Or in
a separate tree under nova's responsibility, like python-novaclient ?

So far we have a 1:1 relationship between a version number and a code
tree, which keeps everything sane from a release management perspective
(for example, the corresponding code tarball has a version number that
covers everything in it). I'd like to keep it that way. So if this
"library" code lives in Nova code, it should just use Nova's own versioning.

If we are talking about a separate library, the versioning can
theoretically use anything (like we do with oslo libraries or Python
client libraries). But then it's better if a given library version can
handle /any/ Nova install, in the same way the Python client libraries
do. That option seems to be adding a new corner case category of
OpenStack project within the "library" project type, with its own
release model... Not exactly a lightweight solution. I'm not sure option
2 is that much of an headache compared to that.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack