[Openstack] best practices for merging common into specific projects

Doug Hellmann doug.hellmann at dreamhost.com
Thu Jul 5 14:17:06 UTC 2012


On Tue, Jul 3, 2012 at 2:59 PM, Gabriel Hurley <Gabriel.Hurley at nebula.com>wrote:

> The notion that copying code is any protection against APIs that may
> change is a red herring. It's the exact same effect as pegging a version of
> a dependency (whether it's a commit hash or a real version number), except
> now you have code duplication. An unstable upgrade path is an unstable
> upgrade path, and copying the code into the project doesn't alleviate the
> pain for the project if the upstream library decides to change its APIs.
>

It does if the API being changed is the one that was copied because it
means the project doesn't have to respond to the change immediately. For
example, if we add something to the rpc library that ceilometer needs, nova
doesn't have to stop what they're doing to handle any potential changes. If
openstack-common was installed as a separate library, there wouldn't be a
(good) way to have both versions installed so ceilometer and nova couldn't
run on the same host (a requirement for the ceilometer agent).

So, I'm +1 on turning common into *several* libraries with their own
versioning scheme, when the components are ready. I don't see a need to
rush that as part of Folsom, though.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120705/9cce04ca/attachment.html>


More information about the Openstack mailing list