1

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?

2 Answers 2

1

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 ).

2
  • I set up the glusterfs using puppet manifest.
    – Chakri
    May 3, 2012 at 18:09
  • I'm pretty sure mscueler's cookbook is for Ubuntu 10.04 and an older version of Gluster that still relied heavily on config files. It won't work with 3.2.x as far as I understand. I'm on ubuntu, and probably will use a remote_file to get the deb package from Gluster and install 3.2.6 which is what they currently recommend for production projects. Still not sure on how to do the configuration though May 3, 2012 at 18:10
-1

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.

3
  • 1
    I'm sorry, not sure I understand your answer. Are you saying that I should essentially write a cookbook that executes the CLI commands necessary to set up a distributed replicated volume every time chef is run, and that Gluster knows how to handle that correctly? (i.e. executing these commands multiple times is idempotent) May 3, 2012 at 16:38
  • I don't know what kind of software you're used to dealing with, but I know of very few where defining a new resource is idempotent, and that's what "the CLI commands necessary to set up a distributed replicated volume" do. Yes, your chef recipe will run on every node, and will have to detect/negotiate whether to create a new resource or attach to an existing one - just like any other distributed system that does its own coordination instead of forcing the user to distribute configs themselves (or automate themselves).
    – Jeff Darcy
    May 3, 2012 at 18:20
  • Ok, for now I'll guess I'll have to go down that road. But it seems like there should be a better way. It would be much better if Gluster either did that detection itself when running the CLI commands, or if you could declare in a configuration file how the volumes should be setup. The old gluster only had 1 file required to do this on the server, and it was pretty self explanatory (see howtoforge.com/…) May 3, 2012 at 19:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .