Re: Roadmap and support questions.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> I tried to write to support@xxxxxxxxxxxxx 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
support@xxxxxxxxxxxxx


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




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux