[Gluster-devel] Upgrade planning

[Martin Fick]

--- On Wed, 8/27/08, Amar S. Tumballi <amar at zresearch.com> wrote:

> Sorry Martin for missing out the mail earlier.

Hey, no prob, I appreciate you response, I know you
guys are usually VERY good at responding, and if
you miss something you usually respond well to a
repost! :)

 
> Generally in testing what I do is just install new
> glusterfs (1.4.xx) on some temporary path. (the only 
> problem comes if  you are using mount.glusterfs, as 
> it gets overwritten), and use glusterfs from temporary
> path (and new ports, spec file) to run tests. Where as
> stable glusterfs will be running in standard path. 
> This works fine for me as i run every instance
> from 'glusterfs', instead of relaying on
> mount.glusterfs and 'mount -t glusterfs'


OK, so it should work if I manage the shared 
libraries then.  Thanks.

Since glusterfs is so flexible/configurable, I suspect
that any substantial deployment will have to deal with
this at some point.  Anytime a client mounts shares
from two different servers it is likely to run into 
this problem.  Should glusterfs perhaps develop a
strategy for administrators to deal with this in a 
simple way?  Whether that be by suggesting a certain
package management strategy to distributors (allowing
mulitiple glusterfs client packages to be installed on
the same machine), or by making the client binaries
become backwards compatible?  I fear that without a
clean (and easy) solution to this serious admins might
shy away from deploying glusterfs in production 
environments.  Thoughts?

-Martin