Re: [Gluster-devel] Roadmap and support questions.

[Anand Avati]

> > I tried to write to address@hidden and got a note that the message
> > was waiting for moderator approval but never got anything beyond that.

sorry for that, a spike in spam content made us change it to a
moderated ID, will look into it right away.

> > Where I work we are interested in Gluster but we are a FreeBSD shop.
> > We would like to see FreeBSD support in the roadmap.

supporting both GlusterHPC and GlusterFS is surely one of our tasks,
though we do not have a committed timeline for them yet.


> > Also we would like to know if there is , or will be commercial support for
> > the product.
>
> I suppose it's too early to ask for commercial support yet (given that the
> first code checkin happened less than 9 months ago)... but nobody will stop
> you to ask for it :-)

Z RESEARCH is already providing commercial support for glusterfs in a
few locations across the globe. We prefer to keep this list a pure
technical discussion list and have support requests come to
address@hidden

> Talking about requests: I re-read my bunch of printouts last weekend, and
> have some suggestions as well (Avati, are you there?):
>
> - to have the servers know about each other helps to avoid - or properly
>         handle - split-brain situations. One might imagine networks with
>         multiple core switches - if the interconnect between them breaks,
>         bad things may happen.

this change is being brought in to AFR translator already where AFR
would work on the server side with knowledge of each other. this will
make it to the 1.3 release itself.

> - in any case, and by any means, one should keep the config as symmetrical
>         as possible. so if a bunch of servers is configured for unify, afr
>         or the like, they should all use the same config (to avoid typos
>         in a single copy), and automagically detect that a reference to
>         a server can be resolved locally.
>         autofs is a good example for such behaviour: a NFS mount would
>         be replaced by a local bind mount.

this is what we too crave for, but thinks like IP addresses being
different not much can be done (when AFR is loaded on server side,
each node will have a seperate config file mentioning its mirrored
peers).

> - the documentation of the translators (as of two weeks ago)needs some
>         restructuring - it's of little use only to know that the translators
>         are there (I can look into the xlator/ subdirectory if I want to know),
>         more important would be a thorough description of the possible options
>         (and trashcan is completely missing). I know, it's a Wiki, and I might
>         add stuff myself, but how can I if I don't know?

we are still working on the documentation, thanks for your pointers.


thanks,
avati

--
Anand V. Avati