Open Stack

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

I was thinking the latter, i.e. a separately packaged library that
ceilometer would depend on with a versioned dependency. 

The result would be that ceilometer could consume only the nova-virt
API, and not all the other irrelevant aspects of nova. Currently by
contrast, the ceilo test-requires pulls in the entire nova tarball:

  http://tarballs.openstack.org/nova/nova-master.tar.gz

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

The former I think, if feasible, as the library would depend on a
fair chunk of the nova innards, common utils, config options etc.
so wouldn't be trivial to split off.


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

OK, well the reason I thought an independent version would be useful
is that the API to this library would well end up being quite slow-
evolving (i.e. not necessarily change across release cycles). We
do have somewhat of a precedent for independently versioned things
within nova (DB migrations, RPC proxies, REST APIs) when the cadence
of change doesn't necessarily match the master release cycle. But
I guess the difference there is that there are not independent
released artifacts related to DB migrations, RPC proxies, or REST APIs.

One potential nasty side-effect of the independent versioning that
just occurred to me, is the circular dependencies that could result,
e.g. nova-virt depends on some utils or whatever in nova-core, whereas
nova-core depends on the virt layer provided by nova-virt. It would
be good to get a read from one of the nova folks on how feasible
it would be to pick those dependencies apart.

Now suppose the the *same* versioning was used as you suggest, would
it still be possible to produce more than one artifact from the nova
release process (e.g. multiple tarballs, binaries)?


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

Well the relationship between the nova code and virt library is quite
a bit more intimate than the python-novaclient library (seeing as the
latter is mediated via a slowly evolving versioned REST API).


> That option seems to be adding a new corner case
> category of OpenStack project within the "library" project type,
> with its own release model... 

Yes, agreed, it does feel like a new thing without a direct precedent.

Cheers,
Eoghan