puppetlabs-corosync: cs_property doesn't get set

[ge...@riseup.net]

[I'm quite new to puppet, so not sure if this is an appropriate question
for this list.]

Hi all,

I'm running Debian wheezy, puppet version 2.7.23. I wanted to have a
look at the corosync module provided by puppetlabs [1].

My code for the test looks quite simple:

class { 'corosync':
enable_secauth => true,
authkey => '/var/lib/puppet/ssl/certs/ca.pem',
bind_address => $ipaddress_eth0,
multicast_address => '239.1.1.2',
}

corosync::service { 'pacemaker':
version => '0',
notify => Service['corosync'],
}

include corosync::reprobe

cs_property { 'stonith-enabled': value => 'false', }
cs_property { 'no-quorum-policy': value => 'ignore', }
cs_property { 'default-resource-stickiness': value => '100', }

After the agent run, corosync and pacemaker gets installed, and the
cluster gets set up. However, despite values for cs_property being set
(incorrect?), these values aren't being recognized, which leads to
ressources being unuseable. The cluster reports:

crm_verify -LV
crm_verify[12971]: 2014/10/08_22:53:36 WARN: cluster_status: We do not
have quorum - fencing and resource management disabled
crm_verify[12971]: 2014/10/08_22:53:36 ERROR: unpack_resources: Resource
start-up disabled since no STONITH resources have been defined
crm_verify[12971]: 2014/10/08_22:53:36 ERROR: unpack_resources: Either
configure some or disable STONITH with the stonith-enabled option
crm_verify[12971]: 2014/10/08_22:53:36 ERROR: unpack_resources: NOTE:
Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid

I thought that the agent has maybe to run twice, which didn't lead to
success however.

I'm quite clueless and appreciate any help!

Thanks,
Georg


[1] https://forge.puppetlabs.com/puppetlabs/corosync

[james.e...@fasthosts.com]

Try running the agent with --debug and --evaltrace to identify what Puppet is doing in relation to those resources.

[ge...@riseup.net]

Hi James,

On 14-10-13 01:27:05, james.e...@fasthosts.com wrote:
> Try running the agent with --debug and --evaltrace to identify what Puppet
> is doing in relation to those resources.

Thanks for your help. The log shows multiple lines like:
Mon Oct 13 13:40:11 +0200 2014 Cs_property[stonith-enabled] (info):
Starting to evaluate the resource
Mon Oct 13 13:40:11 +0200 2014 Cs_property[stonith-enabled] (info):
Evaluated in 0.00 seconds

Because of the size I've put the full log at [1].

Still I'm missing an idea how to debug this further.

Regards,
Georg


[1] http://pastebin.com/raw.php?i=nLs7vDad

[james.e...@fasthosts.com]

Hi,

Since you aren't getting any errors, it would suggest to me that puppet thinks those values are already set correctly and therefore require no further action.
The module essentially parses the output from "crm configure show xml", so I'd check what is being returned in that output for those properties.
You might have to start digging into the provider code to see exactly what it's doing.  The code doing the work for properties is in the file lib/puppet/provider/cs_property/crm.rb.  Time to grab a Ruby hat :)

As somewhat of an endorsement for the module, I'm using it on a 2 node cluster, running Ubuntu 14 and it works fine for properties and primitives, etc.
The one thing that didn't work for me was resource-stickiness.  I had to set that manually as its part of rsc_defaults (not supported by the module), not properties.

[ge...@riseup.net]

Hi,

On 14-10-13 05:58:06, james.e...@fasthosts.com wrote:
> Since you aren't getting any errors, it would suggest to me that puppet
> thinks those values are already set correctly and therefore require no
> further action.
> The module essentially parses the output from "crm configure show xml", so
> I'd check what is being returned in that output for those properties.

Sorry, forgot this. Actually I've checked this last week after using the
module for the first time and getting the errors. The output doesn't
display anything regarding those properties. It seems, that those aren't
being set, as I wrote in my first mail, hence crm_verify -LV showing
errors.

(I've wrapped the output to make it better readable.)

<?xml version="1.0" ?>
<cib admin_epoch="0" cib-last-written="Mon Oct 13 13:44:33 2014" crm_
feature_set="3.0.6"
dc-uuid="gw8.prod.example.com" epoch="9" have-quorum="1" num_updates="4"
update-client="crmd" update-origin="gw8.prod.example.com" validate-with=
"pacemaker-1.2">
<configuration>
<crm_config>
<cluster_property_set id="cib-bootstrap-options">
<nvpair id="cib-bootstrap-options-dc-version" name="dc-version"
value="1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff"/>
<nvpair id="cib-bootstrap-options-cluster-infrastructure"
name="cluster-infrastructure" value="openais"/>
<nvpair id="cib-bootstrap-options-expected-quorum-votes"
name="expected-quorum-votes" value="1"/>
</cluster_property_set>
</crm_config>
<nodes>
<node id="gw8.prod.example.com" type="normal"
uname="gw8.prod.example.com"/>
</nodes>
<resources/>
<constraints/>
</configuration>
</cib>

> You might have to start digging into the provider code to see exactly what
> it's doing. The code doing the work for properties is in the file
> lib/puppet/provider/cs_property/crm.rb. Time to grab a Ruby hat :)

I've had a look at this as well last week.

Using this
crm('configure', 'property', '$id="cib-bootstrap-options"',
"#{@property_hash[:name]}=#{@property_hash[:value]}")
while substituting name and value with the relevant content, from the
cli does work, and the properties are being set.

> As somewhat of an endorsement for the module, I'm using it on a 2 node
> cluster, running Ubuntu 14 and it works fine for properties and primitives,
> etc.

Might there be a difference between Ubuntu and Debian? (Actually I don't
think so, even the doc mentions that the module was tested on Debian
Squeeze; just being quite clueless...)

Thanks,
Georg

[James Eckersall]

Hi Georg,

I had issues when I was first using this module with the primitives.

I ended up adding some debug code to the provider to try and work out what was going on.  I'm sure there are better ways of doing it, but I used File.write to shove log messages into a file on the client in strategic places.

Try adding something in the instances, create and flush methods to see what it's doing.  instances should have any known properties from crm in the instances array.  In the flush method, see if property_hash has any values.

I saw in one of the videos from puppetconf that you can also use pry (http://pryrepl.org/).

require 'pry'

binding.pry

That should give you an interactive ruby shell at whatever point you drop the above code.  Try sticking that in the instances, creates and flush methods.  That way, you can check variable states, etc.

It might sound obvious, but make sure you have the latest version of the corosync module.  I think it was completely rewritten fairly recently.

J

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20141013133258.GU4803%40debian.

For more options, visit https://groups.google.com/d/optout.

[ge...@riseup.net]

Hi,

On 14-10-08 22:57:33, ge...@riseup.net wrote:
> I'm running Debian wheezy, puppet version 2.7.23. I wanted to have a
> look at the corosync module provided by puppetlabs [1].
>

> [...]

>
> After the agent run, corosync and pacemaker gets installed, and the
> cluster gets set up. However, despite values for cs_property being set
> (incorrect?), these values aren't being recognized, which leads to
> ressources being unuseable. The cluster reports:

Using puppet 3.7.1-1 out of Debian jessie fixes this. I think, I won't
debug this further.

Cheers,
Georg

[ge...@riseup.net]

Hi James,

On 14-10-13 19:58:02, James Eckersall wrote:
> I had issues when I was first using this module with the primitives.

After fixing the issue with cs_property, I'm now running into the same
problem like you. Despite cs_primitive being defined in puppet, it
doesn't get created. Did you change the code somehow to fix this?

Thanks,
Georg

[james.e...@fasthosts.com]

Hi,

In the cs_primitive provider, I added debug code to write the updated var to a file in /tmp.  I then tried applying that with crm update as the provider does.  Crm was returning errors to me that the provider wasn't.
I was able to use that to determine that I didn't have all the params set correctly.  For some reason, the provider wasn't reporting invalid params to me.
I've since learned about ruby pry, so that would probably be better than writing debug info to a file.

Regards
J