Werner
Werner

Reputation: 801

Building up an array/string using exported resources

I am in process of writing manifests to configure NXLog in our environment. The idea is to call 'modules' similar to collectd on the clients, for example: nxlog::plugins::syslog and/or nxlog::plugins::nginx etc etc

The step that I am getting stuck in, is building up the route at the end of the config file, the last line would have to contain syslog, nginx as a string value.

Initially I thought of using something such as $input += [$input], and setting the value of $input in each manifest. Then join the array with commas to create a string, but further reading of forums on this hinted strongly that this does not work.

The I thought of using an inline template <%= input.flatten.join(',') %> , but it seems someone else already tried that in a older post without success.

Is there a way to dynamically build up a string value from similar variables in exported resources?

Upvotes: 1

Views: 925

Answers (2)

Werner
Werner

Reputation: 801

if anyone else runs into this - here is how I fixed it, caveat, have to run PuppetDB for this...

  $q_all = (puppetdb_query("
    inventory[certname] {
      facts.app = 'graylog' and environment = '${::environment}'
    }"))

  $members_all = join(sort($q_all.map |$index, $c_name| { "${$c_name['certname']}:9300" }),',')

This will create a comma separated string of the array. I had to include the sort else Puppet returns the string based on last check-in of the guests, the sort removes the possibility of this affecting a change.

Upvotes: 0

John Bollinger
John Bollinger

Reputation: 180093

Is there a way to dynamically build up a string value from similar variables in exported resources?

I am not aware of any such way, and overall, extracting property values from declared resources is poor form. Prior to Puppet 4, it wasn't possible at all, regardless of whether the resources involved were concrete, virtual, or exported.

Instead, you could consider producing the config you want as the effect of collecting and applying the exported resources, which presumably would require using a different resource type than you now do. For example, you might manage the target file via the Concat module, and let the exported resources be instances of Concat::Fragment containing actual pieces of the needed target content. This is a bit easier in cases where the target configuration can reasonably be split among several files, such that you can use Files for the type of your exported resources, but one way or another it can work for you.

Upvotes: 1

Related Questions