echo/anchor won't send an event though

for that code example

notify will

hrmmm... the

exec

actually runs a script which prints a message in big ugly red text, reminding the user to restart nginx (some servers we cannot restart nginx without a maintenance window because it causes a flood of client re-connects) ... the class containing the exec is flagged with

stage => 'deploy'

so the message prints at the end of the agent run ... so in this case, using a

notify

wouldn't hurt anything ...

the exec actually runs a script which prints a message in big ugly red text

....that's what the

notify

resource is for.

notify { 'restart the server':
  loglevel => 'error',
}

i know it's ugly, but i'm still stuck with PE2016.2, although i've been told there's a light at the end of the tunnel, and this time it isn't an oncoming train

yeah, but notify doesn't handle

\033[0;1;37;44m%s\033[0m

in the string to make the message stand out.

unless there is a way to do it, and i've been abusing these machines for the past eight years? wouldn't surprise me ...

Correct, which is what

loglevel => 'error',

is for. That'll colorize. the output of the notify based on Puppet's usual loglevel formatting.

warn

=> yellow

error

=> red

can you also add

stage => 'deploy'

to a

notify

? if so, that might make my life a WHOLE lot easier

some of these puppet runs generate several thousand lines of output, this message needs to be at the very end of the output so when the screen stops moving, the user will be able to see it

Call me dense, but why not just:

if ( $condition ) {
    exec {'x':
      ----
    }
  }

This satisfies your statement:

when declared, doesn't have any real effect on the target server, other than triggering the exec.

(sorry, late to the conversation)

the

exec

runs a shell script containing a

printf

command, which prints a message using ANSI sequences to make it visually stand out ... ideally, the message needs to be printed at the very end of the agent run, so it exists in a class which is declared with

stage => 'deploy'

, and the

exec

has

refreshonly => true

... the code has a config file with

notify => Exec['x']

, but it also needs to notify the same

exec

if a specific custom fact is true

i think in this case i can get away with using a

notify

resource with the same

notify => Exec['x']

attribute. it'll be extra output, but as long as the script's message is at the end, it'll have the desired effect.

Make the

refreshonly

value dependent on the value of that fact. For example:

if $facts['something'] == 'blah' {
  $exec_refreshonly = false
} else {
  $exec_refreshonly = true
}

exec { 'notify-users':
  command     => '/some/script.sh',
  refreshonly => $exec_refreshonly,
}

Or simplified down:

exec { 'notify-users':
  command     => '/some/script.sh',
  refreshonly => $facts['something'] != 'blah',
}

Though do note that trying to get something to run "at the very of of the agent run" is sometimes not trivial. Stages help with that, but if it's the class that's in a stage and there are multiple things within that class, you'll want to order the exec to be after all those other resources too.

This message was deleted.

troubleshooting a hiera lookup issue.

puppet lookup

for a key on a node running puppetserver with puppetdb integration yields the correct value in the right place.

Path "/etc/puppetlabs/code/environments/test_branch/data/groups/service.yaml"
        Original path: "groups/%{group}.yaml"
        Found key: "puppet::server_jvm_min_heap_size" value: "3G"

when running a node on this test branch, this value and some others affecting puppet agent and puppet server conf change to the module defaults. if lookups succeed, the hiera files are all in place and syntactically correct, what else might cause this? the only thing i can think of is if this branch somehow isn’t deployed to a server this agent is pointed at. we’re using srv records, and the environment successfully deployed to all compile nodes.

I have the below hiera.yaml --- version: 5 defaults: datadir: "data" data_hash: "yaml_data" hierarchy: - name: "cluster" paths: - "cluster/%{facts.cluster}.yaml" - name: "os" path: "os/%{facts.os.name}%{facts.os.release.major}.yaml" - name: "role" paths: - "data/role/%{trusted.extensions.pp_role}.yaml" - "role/%{facts.role}.yaml" - name: "Common" paths: - "common.yaml" When applying the puppet agent it is not applying the files under data\role\pp_role*.yaml as expected on puppet 7, on puppet 4 agent the configuration data\role\pp_role*.yaml is getting applied as expected. Below is the manifests\site.pp content

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

Hi all! Do we have news on the Jira migration?

Ah, have just seen the answer from @binford2k: in progress

This message was deleted.

goodnews 🧑‍🏫Puppet Forge is about to start up in #CFD8Z9A4T

This message was deleted.