openstack team mailing list archive

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Tue, Jun 19, 2012 at 11:07:05AM -0700, Monty Taylor wrote:
> I'm going to top-post, because there is a whole other thing which is not
> a response to points below. Basically, this is yet-another-instance of
> two competing and partially contradictory sets of use cases and usage
> patterns that we're trying to find the right compromise for.
> 
> Tying client libs to server releases is really handy for the distros. It
> is terrible for the public cloud implementations who are doing rolling
> releases - not in as much as it effects the public cloud's ability to
> use the client libs - they can obviously pull trunk client lib from git
> and use that for intra-server communication just fine as part of their
> deployment. Rather, it is a terrible experience for the end-users of
> OpenStack public clouds.

With my distro hat on, I don't actually think tying client libs to
server releases is a particularly big factor. What the absolutely
critical factor is for distros, particularly enterprise distros, is
that /any/ client lib release be capable of talking to /any/ server
release. Mandating matched versions of (client,sever) is a really
undesirable because it is inevitable that at some point deployments
will end up with a mix of openstack server releases.

So if the client libs are on a more frequent release cycle than the
server releases, that is fine from a distro POV. Though I'd expect
you'd want the client libs release cycle to allow for it to periodically
line with the major server releases for convenience.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|