scrape_job exported resources are ignoring custom collect dir

[ndelic0]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.4.2
• Ruby: ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]
• Distribution: CentOS Linux release 7.8.2003 (Core)
• Module version: 9.1.0

How to reproduce (e.g Puppet code you use)

In profile we're exporting scrape_jobs

$scrape_job_labels = { 'alias' => $::facts['fqdn'] }
@@prometheus::scrape_job { "${::facts['fqdn']}_${_port}":
  job_name    => $name,
  targets     => ["${::facts['fqdn']}:9100"],
  collect_dir => '/srv/prometheus/file_sd_config.d',
  labels      => $scrape_job_labels,
  tag         => $_tag,
}

In server profile these resources are collected with :

Prometheus::Scrape_job <<| job_name == $job_name |>> {
  collect_dir => '/srv/prometheus/file_sd_config.d/',
  notify      => Class['::prometheus::service_reload'],
  tag         => $_tag
}

What are you seeing

File configs are created in /etc/prometheus/file_sd_config.d/

What behaviour did you expect instead

File configs are created in /srv/prometheus/file_sd_config.d/

Output log

Any additional information you'd like to impart

[towo]

@ndelic0 Having a quick look at the code, I can't see any particular reason why this definition would be ignored. Do you have some leftover code somewhere else saving to the spot? Is it only appearing in /etc/prometheus/file_sd_config.d - and aren't the files maybe just leftovers from a previous change?

[ndelic0]

@towo Thanks for looking into this. Solved the problem with refactoring the profile. Basically replacing class { 'prometheus::server'} call with main class class { 'prometheus': }. Missed this issue #208. Maybe this is worth documenting.

[towo]

We're considering refactoring the module entirely with regard to the server class, thanks for the input. 👍