Enterprise - Purging files no longer managed fails to notify correct service

[dzeleski]

Description of problem

• Remove check definition
• After running puppet the file is removed but the wrong service is restarted and the config is never applied correctly.

Command used and debugging output

Platform and version information

• Your OS: centos 7 and rhel 7
• Your version of Puppet: 2017.3.2
• Your version of Sensu: Core: 1.1.2-1 Enterprise: 2.6.2-1
• Your version of this module: 2.39.0

Anything else to add that you think will be helpful?

This is being managed here via a file resource: https://github.com/sensu/sensu-puppet/blob/master/manifests/package.pp#L188
It is being managed correctly for core here, but it does attempt to restart a disabled service on enterprise: https://github.com/sensu/sensu-puppet/blob/master/manifests/server/service.pp#L24
But is not being managed correctly here for enterprise: https://github.com/sensu/sensu-puppet/blob/master/manifests/enterprise.pp#L85

[ghoneycutt]

Hi @dzeleski Thanks for submitting this issue.

Can you please describe what the correct actions should be so we can work toward that goal?

[dzeleski]

@ghoneycutt After a json config is either added/changed/removed the sensu-enterprise service needs to be restarted (or the config files reloaded live if thats an option yet). Currently for each definition we have to add a notify for when something is changed or added, this works but in order to remove something we would have to use ensure => absent let puppet run on all N nodes and then remove the resource from being declared instead of just removing the definition from code and allowing the purge => true option to handle that for us.

Example of that notify:

  sensu::check{ 'cl-cpu-load_pct-base':
    command             => 'check-cpu.rb',
    # handlers            => 'linux_handler',
    interval            => 60,
    subscribers         => 'base',
    standalone          => false,
    occurrences         => 10,
    low_flap_threshold  => 80,
    high_flap_threshold => 90,
    notify              => Service['sensu-enterprise'],
  }

[dzeleski]

@ghoneycutt I believe the fix would be to add Class['sensu::package'], to the subscribe here: https://github.com/sensu/sensu-puppet/blob/master/manifests/enterprise.pp#L90

Edit: either that or subscribe to the dirs changing? https://github.com/sensu/sensu-puppet/blob/master/manifests/package.pp#L188 Im not sure if there will be dependency cycles by doing that with the enterprise service as I have not tested these recommendations at all :)

[ghoneycutt]

Thanks @dzeleski

Are you able to test and see if that one liner fix works for you?

[dzeleski]

@ghoneycutt wont be able to get to it today, I can do it first thing tomorrow if that timeline works for you guys?

[ghoneycutt]

Thank you for testing!

[alvagante]

In the referenced commit I added the subscribe to the whole sensu::package class in the sensu-enterprise service. It restarts the service when files are purged and there're not apparent dependency cycles. Want to test this a bit more anyway, and add a spec tests, so PR still not there.

[alvagante]

Tests added, no dependency cycles even if we notify the whole sensu::package class.
The reason for this (which actually suprised also me at first) is that there's no explicit relationship to sensu::enterprise in https://github.com/sensu/sensu-puppet/blob/master/manifests/init.pp#L649 and I suppose the "historical" reason is to avoid actual dependency loops that the other ubscribed resources in https://github.com/sensu/sensu-puppet/blob/master/manifests/enterprise.pp#L90 would have. So I suppose it's ok to subscribe the whole sensu::package class.

[ghoneycutt]

Released in v2.50.0