Seems impossible to find any info on configuration files for Gluster's most recent version (3.2.x). I'd like to use configuration files as opposed to the CLI because I'd like to automate configuration with chef.
Is this possible? When I googled this, all I found was this, which was pretty useless: http://community.gluster.org/q/does-glusterfs-support-configuration-files/
How does one do this?
Incidentally, I'm involved in doing the exact same thing now and have come up with some working solution.
Assumption: Using EL6 platform.
The Gluster package for 3.2.x is available from EPEL repo. apart from Gluster.org. There are quite a lot of differences from how the package from EPEL works. The package from Gluster.org is purely command-line driven. The package from EPEL has a server and client package and honors the config files. Note that, you will have to ask it to load a config file by modifying the relevant glusterfs config file under /etc/sysconfig.
Apparently, there is a cookbook by mschueler, which sets up AFR (Automatic File Replication) across 2 storage servers. I haven't tested it though as it was completely ubuntu specific but still should work here.
I was testing AFR using client side replication and was able to make it work purely by config files.
I'm skeptical to use the package from EPEL as I read that Gluster is moving away from config file based configuration to completely command-line based confgiuration. ( I could be wrong on this and need confirmation ).
Any API/CLI/whatever for any package can ensure the consistency/validity of the generated configuration as changes are made, migrate configs across software updates, etc. All of that gets thrown away when you generate the configuration files directly from external automation tools, so that should be a last resort generally and GlusterFS is no exception. I had to do that for HekaFS but, even as someone in a position to influence GlusterFS changes that might break HekaFS-generated configurations, I still consider it an unfortunate necessity.
The configuration-file format itself is very simple. I wrote a Python parser/generator for it in an hour or so. Generating a correct set of configuration files, in terms of satisfying dependencies or layering constraints between translators, or setting all the necessary options, is a bit harder. We also support live configuration changes without restarting daemons, and generating the RPC messages involved to notify them of config changes is all but impossible (not to mention insecure) outside of the current management infrastructure, so a chef-based approach based on rewriting config files would be demonstrably inferior to what's there already.
If there are things that need to be done to make chef integration with the CLI easier, by all means let me know via Bugzilla, email, IRC, whatever. I'll be glad to help with that, but not with an approach that has been tried before and always caused massive breakage.