Puppet module 4.x role/profile structure

Sensu Go
1

Hi,

I hope this is the right place to start a discussion like this.
I’m curently using the official Sensu puppet module to manage my Sensu Go backend and agents.

My puppet infrastructure is built around the role/profile model.
It seems like such a structure is not supported anymore with the latest version of the Sensu puppet module and it’s forcing me to put module parameters into Hiera directly.

Example:
I have two profiles for, profile::sensu::agent and profile::sensu::backend.
On my backend-nodes they’re both included.
And this is what they looked like before upgrading to the latest 4.x version of the module.

# @summary Sensu agent profile
class profile::sensu::agent (
  Array $backends = [],
  Hash $config = {},
  Hash $scripts = {},
) {
  class { 'sensu::agent':
    backends     => $backends,
    config_hash => $config,
  }
  ...
}

# @summary Sensu backend profile
class profile::sensu::backend (
  String $password,
  Hash $checks = {},
  ...
) {
  class { 'sensu::backend':
    password        => $password,
    old_password    => 'P@ssw0rd!',
    checks          => $checks
    ...
  }
}

The agent profile is working fine with version 4.x, the backend profile is causing, errors, though:

  • password/old_password was moved to Class['sensu']
  • checks/assets/… was moved to Class['sensu::resources']

Defining class {'sensu': password => $password, ...} in the backend doesn’t work, though, because it’s already included by sensu::{agent,backend}.
Defining class {'sensu::resources': checks => $checks, ...} doesn’t work, either, because it’s already included by sensu::{agent,backend}.
So the only way to migrate my existing profile::sensu::backend class to be compatible with version 4.x is to just include sensu::backend and define all class parameters (like sensu::resources::checks, sensu::password, …) through Hiera.

Am I missing something?
Is there any way around this (apart from patching the module in horrible ways)?

2

You have to do class { 'sensu': ... } before the sensu::backend and/or sensu::agent classes. If you want to include both profiles on the same host then I’d advise a 3rd profile called something like profile::sensu::common and define sensu class there and include that profile in both agent and backend profiles. In Puppet a class {} done before an include is fine but an include first will cause duplicate declaration errors.

3

Oh… didn’t know that, thanks!
I created profile::sensu::common defining class {'sensu::resources: } and class {'sensu': } (in that order, because sensu includes sensu::resources).
It’s complaining about something else now, though:

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: no parameter named 'path' (file: /etc/puppetlabs/code/environments/master/modules/sensu/manifests/cli.pp, line: 84) on Sensuctl_config[sensu] (file: /etc/puppetlabs/code/environments/master/modules/sensu/manifests/cli.pp, line: 84)

It looks like that’s not an issue related to my usage of the module/wrong order of includes, though?

The sensuctl_config resource should have that parameter: https://github.com/sensu/sensu-puppet/blob/master/lib/puppet/type/sensuctl_config.rb#L20
But for some reason it’s still throwing an error…

4

Are you using multiple environments and is this in non-production environment? Often when Puppet fails to pick up new type properties or parameters it’s because environment isolation with types doesn’t work like you’d expect. It’s possible for environments to spill into other environments and cause type conflicts.

https://puppet.com/docs/puppet/latest/environment_isolation.html

I would recommend looking at running puppet generate types for your environments if you are indeed using environments.

5

No, I’m currently only using one environment (master).
Running puppet generate types --environment master still solved it, thanks!