Open Stack

Doug Hellmann wrote:
>>     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.

OK, that makes sense to me. If we can piggy-back on oslo for this, it's
even better (no need to create a corner case project).

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

There is the question of stable releases, and PyPI insufficient support
for that (same concerns as in the oslo versioning thread). I'm also a
bit worried that we'd have to maintain a weird compatibility matrix,
like "you need 1.6 to talk with Nova 2013.1", but since it's not really
user-oriented, maybe it doesn't matter that much.

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

My understanding of option 5 is that the library would be use by
ceilometer to access Nova, not the other way around ?

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack