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

Eoghan Glynn eglynn at redhat.com
Wed Nov 21 17:06:09 UTC 2012



> >> 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.
> > [...]
> > 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)?
> 
> It's not possible with the current CI setup we have, and I'd argue
> it's not desirable. It's good that a given source tree results in a
> given source code tarball...

OK.
 
> Doug seems to have a slightly different vision for option 5, which
> sounds much more doable to me (external library).

Yeah, it was the unpicking of the mutual dependencies between the
new library and the nova core that made me a bit leery of completely
externalizing it. But if that's do-able, then external is probably
the way to go.
 
> >> 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.
> 
> I fear that when the ML thread favored option 5 it did not really
> take into account the added complexity on the release side of things
> (probably my fault for not diving into it earlier). All things
> considered, it might not be the simplest route.

I guess there other concerns than simplicity influencing that discussion,
such as eliminating long round-trips for the query path (i.e. nova-api-->
RPC-->nova-compute), also avoiding usage of private internal nova APIs
(i.e the compute RPC API).

So while this approach would introduce new complexity to the release
management side, do you think it's a show-stopper level of complexity,
or a more a give-us-pause-to-ensure-we-really-need-to-do-this level?

Cheers,
Eoghan



More information about the OpenStack-dev mailing list