| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This avoids errors if you have only one brick vs. many.
A small note: I haven't tested this ad-infinitum, but since nobody who
has tested it privately has complained, I'm sticking this in git master
so that it gets wider testing. If anyone has issues, please report!
|
| |
|
|
| |
Although if you remove all the features, it's not as awesome anymore :)
|
| |
|
|
|
|
| |
I wasn't able to test this patch, for lack of hardware at the moment. A
patch for: https://github.com/pradels/vagrant-libvirt/issues/162 would
also help solve my testing issue. Please report any issues!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've had most of this patch in my head for at least a week, and I
finally got the time to implement it! If you are building a symmetrical
cluster, that has consistent device naming across all of the hosts, then
this patch is the magic that should make your life _significantly_
easier. (*cough, cough*: Ben England...)
In the corner case that some of your device have different names, you
can still use this feature in conjunction with the other parameters to
first set global defaults, and then override as needed.
If you don't specify an overriding parameter (such as $count) then the
number of elements in this array will be used as the brick count!
Please note that this patch provides the $brick_params_defaults option
which is different from the $brick_param_defaults option which will
still work, and is useful in conjunction with this option as the way to
set brick defaults across the whole cluster.
For more questions you'll be happy to see that this patch comes with
documentation and example updates.
|
| |
|
|
|
|
|
| |
This isn't essential, as ensuring this is race-free is really up to
glusterfs, but with this patch you reduce the likelihood to ~0% that
you'll see a: "volume set: failed: Another transaction is in progress."
error. The error isn't harmful, but now we'll see less unnecessary red.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
* Don't use this feature unless you _really_ know what you're doing.
* Managing chained volumes is much harder than managing normal ones.
* If some of the volumes in the cluster use this, and others don't, then
you'll probably have an even crazier time with management.
* Please verify my algorithm and feel free to suggest changes.
* Some edge cases haven't been tested.
* This patch breaks out brick layout ordering into individual functions.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This adds support for setting volume set groups which are groups of
properties that are set all at once on a volume. This is managed in a
clever way, so that if the definition of what a certain group contains
gets updated by the package manager, your volumes will get updated too,
on the next puppet run.
|
| |
|
|
|
|
| |
This is useful for environments that don't include fping.
Usage of fping (or similar) is still recommended to make you less likely
to get an error on volume creation if one host isn't up.
|
| |
|
|
|
| |
This patch adds support to specify the brick device values as a hash.
It also allows for separate defaults that apply to the whole cluster.
|
| | |
|
| | |
|
| |
|
|
| |
See: https://bugzilla.redhat.com/show_bug.cgi?id=987555 for info.
|
| |
|
|
| |
I've updated wrapper.pp too, but I haven't tested it recently.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds VRRP integration to puppet-gluster. All you need to do is
set vrrp => true, and set a vip, and the rest should happen
automatically. The shared keepalived password is built by a distributed
password selection algorithm that I made up. Feel free to review this if
you'd like. It's probably as secure as your puppet server and clients
are. If you'd prefer to specify each token manually, you can do so in
the gluster::host password argument, or you can set one global vrrp
password in the gluster::server or gluster::simple classes. There's a
chance that you'll see a bit of VRRP flip-flop when you add/remove hosts
because the distributed password should change. The benefit is that by
default you don't need to set or manage any of those passwords!
This doesn't add firewalling so that the VIP can be used by clients.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduced a split between repo management and version choosing.
You can now:
* Choose a package version or leave it at the default (latest).
If you choose a package version it must include the release string.
eg: in foobar-3.2.1-42.el6 the release is 42.el6
This doesn't check to see if your version is valid!
* Choose whether you want a gluster repo added automatically.
If you did specify a version, it will pick the correct repo.
This doesn't check that the repo for your os/version exists!
|
| |
|
|
| |
This should help users figure out they have a DNS problem sooner.
|
| |
|
|
|
| |
Support for other operating systems will have to come later, even if
this needs to be refactored. For now, CentOS/RHEL are automatic.
|
| | |
|
|
|
This patch adds preliminary FSM support. This will be used and abused
more extensively in later patches. Automatic brick ordering is an
advanced feature and is meant for experienced puppet users. Changing the
available bricks before the cluster is built is not currently supported.
For that type of magic, please wait for gluster::elastic.
This feature expects that you name your bricks and hosts intelligently.
Future patches will recommend a specific nomenclature, but for now as
long as the brick paths and hostnames follow a padded, incrementing
integer pattern, with a common prefix, you shouldn't see any problems.
|
