Cannot create two colocation constraints on the same resource.

[kristvanbesien]

When I declare two constraints on the same resrource only one gets created.

For example:

pacemaker::constraint::base{'mysql-avoid':
constraint_type => 'location',
first_resource => $mysql_resource_group_name,
location => $cluster_quorum_host,
score => '-INFINITY'
}
pacemaker::constraint::base{'mysql-prefer':
constraint_type => 'location',
first_resource => $mysql_resource_group_name,
location => $mysql_preferred_host,
score => 'INFINITY'
}

The idea here is to make mysql prefer one host, and avoid another. However, only one constraint gets created.

The reason is that in the base.pp the "unless" clause tests on the presence of the resource name in the ouutput of "pcs location show". As a result the second resource is not created on the host.

My solution was the following modification:

replace:
unless => "/usr/sbin/pcs constraint location show | grep ${first_resource} > /dev/null 2>&1",
with:
unless => "/usr/sbin/pcs constraint location show --full | grep ${name}",

I can send a patch if you want (but I'm a complete git newbie...)

[radez]

This is a known issue in the module. I'm in the middle of rewriting these pacemaker resources to be puppet providers instead of just classes. I'll leave this ticket open and notify you when I have it updated. It should be in the next week or so. I would love your testing once it's updated.

[radez]

Thought I'd offer, even though this feature will be moved into a puppet provider, if you'd like to go through the exercise of forking, patching and submitting a pull request, I'd be happy to work through the github process with you.

[radez]

I've pushed an update for colocation. If you use pacemaker::constraint::colocation instead of the base class it will call into the new code and should take care of basic colo support.

let me know how it works for you.

[kristvanbesien]

I've tested the "location" resource and this seems to work. I for example now have the following code in my manifest:

pacemaker::resource::ip{"${mysql_virtual_ip}":
ip_address => $mysql_virtual_ip,
group => $mysql_resource_group_name,
cidr_netmask => $mysql_virt_ip_cidr_mask,
}

pacemaker::resource::filesystem{"${mysql_shared_storage}":
device => "$mysql_shared_storage_device",
directory => "/var/lib/mysql/",
fstype => $mysql_shared_storage_type,
group => $mysql_resource_group_name,
require => Package['glusterfs-fuse'],
}

pacemaker::resource::lsb{'mysql':
name => 'mariadb55-mysqld',
group => $mysql_resource_group_name,
require => [Pacemaker::Resource::Ip["${mysql_virtual_ip}"],Pacemaker::Resource::Filesystem["${mysql_shared_storage}"]],
}

pacemaker::constraint::location{'mysql-avoid':
resource => $mysql_resource_group_name,
location => $cluster_quorum_host,
score => '-INFINITY'
}

pacemaker::constraint::location{'mysql-prefer':
resource => $mysql_resource_group_name,
location => $mysql_preferred_host,
score => 'INFINITY'
}

In this case the two location constraints get created on the resource group. This has the intended effect.

[krist@dc1-03 ~]$ sudo pcs constraint --full
Location Constraints:
Resource: os_db
Enabled on: dc1-03.local (score:INFINITY) (id:loc-os_db-dc1-03.local)
Disabled on: quorum-03.local (score:-INFINITY) (id:loc-os_db-quorum-03.local)

So this worked.
However, I also wanted to test the colocation resource, and there I ran in to a problem:
I added this:

pacemaker::constraint::colocation{'mysql-ip':
source => 'mysql',
target => $mysql_virtual_ip,
score => 'INFINITY'
}

The idea is to define colocation between my mysql resource, and the virtual ip.

However, this didn't work:

Error: Resource 'mysql' does not exist
Error: pcs create constraint failed

The reason is actually obvious. The resource created by pacemaker::resource::lsb{'mysql':} is called lsb-mariadb55-mysqld. The same for the IP resource, which is called ip-172.16.1.15, not 172.16.1.15...

This is because the pacemaker resource names are generated within your resources, based on the puppet resource names. It would be nice if we could somehow override this, so we don't need to duplicate the way these are derived in our puppet manifests.

[radez]

Great feedback, thankyou.

I think we could have two options here, possibly both could be handled simutaniously
a) Your suggestion, override the pcmk resource name so that they are user defined.
b) enable handling a puppet resource can be passed instead of a string. then puppet could pass information between its resources so the end user doesn't have to manage these names (which I think is what I was originally shooting for.)

Thoughts?

[kristvanbesien]

Handing over a puppet resource sounds like a great idea. Being able to do something like this makes a lot of sense intuitively...

pacemaker::constraint::colocation{'mysql-ip':
source => Pacemaker::Resource::lsb['mysql'],
target => Pacemaker::Resource::Ip[$ip],
score => 'INFINITY',
}

I have no idea how hard this would be. And if it could coexist with the other option. Having both would be nice, in case you need to apply puppet to an already existing cluster...