--- On Wed, 8/27/08, Amar S. Tumballi <amar@xxxxxxxxxxxxx> 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
