Nagios_contact in multiple contactgroups

[Jonathan Gazeley]

Hi all,

I'm using hiera with puppet to create Nagios contacts. However, it seems
that Nagios contacts do not get put into multiple contact groups. No
errors are thrown, but I think this is wrong.

After running the below code the contact "jg4461" is only placed in the
"resnet" contactgroup (see bottom). Is this expected behaviour?

Thanks,
Jonathan

## nagios/user.pp
define nagios::user ($nagiosuser=true, $ensure=present, $comment, $uid,
$gid, $groups) {
if $nagiosuser == true {
# create nagios user
@@nagios_contact { $name:
ensure => $ensure,
contact_name => $name,
alias => $comment,
use => 'generic-contact',
email => "${name}@bristol.ac.uk",
contactgroups => $groups,
}
}
}


## nagios/init.pp
$unifiedusers = hiera("unifiedusers")
create_resources("nagios::user", $unifiedusers)



## common.yaml
unifiedusers:
jg4461:
nagiosuser: true
comment: Jonathan Gazeley
gid: resnet
uid: 56933
groups:
- sudoers
- resnet
- netops
- superadmins




## nagios_contact.cfg
define contact {
alias Jonathan Gazeley
contact_name jg4461
contactgroups resnet
use generic-contact
}

[jcbollinger]

On Monday, January 13, 2014 5:38:39 AM UTC-6, Jonathan Gazeley wrote:

Hi all,

I'm using hiera with puppet to create Nagios contacts. However, it seems
that Nagios contacts do not get put into multiple contact groups. No
errors are thrown, but I think this is wrong.

After running the below code the contact "jg4461" is only placed in the
"resnet" contactgroup (see bottom). Is this expected behaviour?

I've always hated the documentation of Puppet's nagios_* resource types.  It is good for showing the properties defined for each type, but nearly useless for conveying how to use them.  As a result, I don't use them, but I nevertheless have two guesses about what may be going on:

1. Puppet is filtering the declared contactgroups to remove groups that are not defined in the target file.  That would probably happen as-of the time it applies the nagios_contact resource, so if you are relying on Puppet also to manage the relevant contactgroups then the relative order matters.
2. Puppet expects a comma-delimited string of contact group names (as will appear in the target config file) rather than an array.  Upon receiving an array, it somehow chooses just one of its elements.

I'm leaning toward (1), since I'm having trouble guessing out how Puppet would end up selecting the second element of the array instead of the first or the stringification of the whole array.


John

[Jonathan Gazeley]

On 13/01/14 23:00, jcbollinger wrote:

Puppet expects a comma-delimited string of contact group names (as will appear in the target config file) rather than an array.  Upon receiving an array, it somehow chooses just one of its elements.

It seems your second suggestion was correct. The nagios_* types expect a comma-separated string, not an array. This is ridiculous and bizarre behaviour and seems to defy the whole point of having a managed resource, and there is an old, open bug for it.

http://projects.puppetlabs.com/issues/4020

There's a workaround using templates as a filthy hack:

# manifest.pp
nagios_host { "$fqdn":
  address => "$ipaddress",
  hostgroups => template("join_hostgroups.erb")
}


# join_host_groups.erb:
<%= nagios_hostgroups.join(',') %>


Thanks,
Jonathan

[jcbollinger]

On Tuesday, January 14, 2014 5:42:54 AM UTC-6, Jonathan Gazeley wrote:

On 13/01/14 23:00, jcbollinger wrote:

Puppet expects a comma-delimited string of contact group names (as will appear in the target config file) rather than an array.  Upon receiving an array, it somehow chooses just one of its elements.

It seems your second suggestion was correct. The nagios_* types expect a comma-separated string, not an array.

Go, me!

 

This is ridiculous and bizarre behaviour and seems to defy the whole point of having a managed resource, and there is an old, open bug for it.

http://projects.puppetlabs.com/issues/4020

I think "ridiculous and bizarre" is a bit strong.  It's strange that the type selects one element and ignores the rest, but it's not so surprising that's what's wanted in the first place is whatever string is supposed to be plugged in to the corresponding hole in the Nagios config file.  That's even a viable way to read the documentation for the type.  And I certainly don't understand what any of this has to do with "the whole point of having a managed resource".

 

There's a workaround using templates as a filthy hack:

# manifest.pp
nagios_host { "$fqdn":
  address => "$ipaddress",
  hostgroups => template("join_hostgroups.erb")
}

You seem angry about this.  I don't understand why.

Anyway, if you have Puppetlabs's "stdlib" add-in module installed, then it provides a join() function that can replace the template.  Or at minimum it would probably be better to use an inline_template() instead of an external one.


John

[Jonathan Gazeley]

On 14/01/14 23:27, jcbollinger wrote:

On Tuesday, January 14, 2014 5:42:54 AM UTC-6, Jonathan Gazeley wrote:

 

This is ridiculous and bizarre behaviour and seems to defy the whole point of having a managed resource, and there is an old, open bug for it.

http://projects.puppetlabs.com/issues/4020

I think "ridiculous and bizarre" is a bit strong.  It's strange that the type selects one element and ignores the rest, but it's not so surprising that's what's wanted in the first place is whatever string is supposed to be plugged in to the corresponding hole in the Nagios config file.  That's even a viable way to read the documentation for the type.  And I certainly don't understand what any of this has to do with "the whole point of having a managed resource".

John,

I'm sorry for my outburst yesterday - quite embarrassed to read my message back again :\ I was just a bit frustrated to run into bugs and/or unexpected behaviour when I also had some of our dev/ops guys on my back wondering when I was going to fix their monitoring notifications.

"Hulk smash, Hulk do Nagios configs!"

I think what I meant was - data structures within Puppet and Hiera are almost always handled as arrays or hashes, and when you call upon other classes and resources you would tend to pass it an array or a hash. I was surprised that this isn't the case for nagios_* types, which expect a comma-delimited format.

 

There's a workaround using templates as a filthy hack:

# manifest.pp
nagios_host { "$fqdn":
  address => "$ipaddress",
  hostgroups => template("join_hostgroups.erb")
}

You seem angry about this.  I don't understand why.

Yeah, today I'm not sure why either. I guess it seems a less elegant solution (and potentially more expensive in terms of resources on an already busy puppetmaster). It's the first time I've had to do something like this (I guess that makes me lucky).

Anyway, if you have Puppetlabs's "stdlib" add-in module installed, then it provides a join() function that can replace the template.  Or at minimum it would probably be better to use an inline_template() instead of an external one.

After my email yesterday, I changed my approach to use an inline_template() which works nicely. Also good to know that there's a join() function for for joining arrays - thanks for the tip. We do already have "stdlib" installed, but only as a dependency for other forge modules - I've never called upon its functions myself. Thanks for the tip - I'll check it out tomorrow (now after 4pm here and we're not allowed to make changes in case we break stuff!)

Sorry again for my rage, and thanks for your advice. If you're ever in Bristol (UK), I'll buy you a pint :)

Cheers,
Jonathan