and the agent uses different colours, or otherwise makes them "stand out" in what otherwise looks like a wall of output?

For example:

notify { 'reminder':
  message  => 'This is an important reminder',
  loglevel => 'warning',  # This makes the log entry for this resource yellow
}

Yeah, the different log levels have different colors in the agent's output.

warning

is yellow.

err

,

crit

, and higher are red.

(also, there are ANSI colour sequences whenever i use

puppet agent -t --debug

)

#justsayin

😄

(also, there are ANSI colour sequences whenever i use

puppet agent -t --debug

)

#justsayin

😄

Right.... but that's not Puppet parsing color codes into colored output. That's your terminal/shell not interpreting the ascii codes into colors.

For example, when you do

puppet agent -t | tee output.txt

you'll see that. (and by the way, use

puppet agent -t --no-color | tee output.txt

to get rid of those codes if you don't want them)

((or use

less -R output.txt

to re-interpret the codes into color))

i know, i was messing with you ... it's been a long day, i need to make whatever jokes i can, even if they're bad^H^H^Hdad jokes

and

less -R

is one of my favourite commands

Right.... but that's not Puppet parsing color codes into colored output. That's your terminal/shell not interpreting the ascii codes into colors.

i had never thought to use

loglevel

with a

notify

before ...

warning

is good enough for what i need, plus the people using this stuff aren't used to seeing yellow so it'll catch their eye without failing the whole catalog, which is what i'm after.

thank you again for pointing out something i should have seen for myself years ago

I'm thinking of system stuff that's outside the scope of the module. So for example, the module manages postfix, needs a package that is available via epel. On a live system, no problem because I have a base module/profile that goes and configures that. In my litmus acceptance however, I don't. So I'm ideally looking for a way to run adhoc commands on the litmus target system to configure those deps. I suppose I could use an epel module as a test dependency in this scenario, just seems a bit ott.

For example, I use

run_shell()

here to test the behavior of my module under certain edge cases: https://github.com/natemccurdy/yumrepos_fact/blob/main/spec/acceptance/yumrepos_spec.rb#L33-L34

message has been deleted

This message was deleted.

If your Master is stuck at this point for.. hours (9) that's bad right? 🙂

yah

Poke around in another shell to see what SystemD is bugging about.

I'll give it another hour or two. This linux machine and i don't get along and i think it needs to learn some respect first

check your postgres and puppetdb logs

is it possible to update the built-in

gce

fact at all? tl;dr the amount of ssh keys we have added to projects trips over tthe

fact_value_soft_limit

config key, and i'd like to just omit the

gce.project.attributes.'ssh keys'

key rather than up the limit (https://www.puppet.com/docs/puppet/7/core_facts.html#gce)

I bet you're using ssl for your puppetdb connection and some part of the puppetdb startup is locked @Les Shiner

I've had that issue a few times

@Lumiere you're amazing

the postgres logs will likely shine good light on what the issue is

but for me, it was that the migration code in puppetdb was having an ssl error

ooo how did you resolve that?