Open Stack

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

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

Yes, down with special cases! :-)


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

I thought that option represented moving the virtualization code out of
nova into a library that was used by both components for talking to the
hypervisor. That introduces a new dependency, but neither component is
communicating with the other so there is still no dependency between nova
and ceilometer (in fact, removing our current dependency on nova is part of
the motivation for these changes).

Doug


>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121121/ca19a8c7/attachment.html>