Open Stack

On Wed, Nov 21, 2012 at 9:25 AM, Thierry Carrez <thierry at openstack.org>wrote:

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

Whichever provides more protection against API changes later. The idea is
to stop the thrashing we've got going on now because ceilometer is using
internal bits of nova that change without warning. FTR, we knew that was a
bad idea, but in the interest of expedience went ahead with it anyway.
We're working on cleaning it up now.


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

It would definitely be the nova team's responsibility, although I am sure
Eoghan and others from the ceilometer team will have input as well.

If we don't move the library out of the main nova code base, then we will
have to be very vigilant to avoid introducing dependencies on global state
(cfg.CONF), API changes, etc. For that reason, I think the simplest
long-term solution would be to create a new git repo managed by the nova
team with the code for this library and then treat it in the same way we
plan to treat the oslo libraries. It should install into its own namespace
(i.e., not the nova package, maybe oslo-virt?) and have a separate version
number (the triplet Eoghan proposed would work for this). The OpenStack
projects that use it would need to declare which version they want and
within an OpenStack release we would have to coordinate so that nova and
ceilometer don't require different versions, just as with other libraries.


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

Why do you propose that the library needs to support any version of nova? I
don't see why it would be treated any differently than any other dependency
of nova or ceilometer. It isn't an API in the sense that the library would
be used to communicate with nova. It would be something nova uses, like
anyjson, gevent, or libvirt.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121121/0032e13d/attachment.html>