Right... Let me look it up 😄 Haven't done much Puppet lately 🙈

oh sorry, the code obviously only corrects for variables with a second set of

::

Otherwise when you were referring to a topscope variable (eg. from an enc or set in site.pp) it'd correct it to a local scope variable (which would be bad)

(https://github.com/mmckinst/puppet-lint-top_scope_facts-check might complain about them though assuming they should be facts unless you whitelist them. This is why I've always wanted a

enc

hash to compliment the

facts

hash)

(https://github.com/mmckinst/puppet-lint-top_scope_facts-check might complain about them though assuming they should be facts unless you whitelist them. This is why I've always wanted a

enc

hash to compliment the

facts

hash)

I hate threads -.-

Ah ok, so it's just complains about variables with a second

::

🤔 Yeah, make sense 😄 Thanks for looking this up! 🙂 I will close the issue as invalid.

Ah ok, so it's just complains about variables with a second

::

🤔 Yeah, make sense 😄 Thanks for looking this up! 🙂 I will close the issue as invalid.

@josh Can we have an

enc

hash in Puppet 8 please? 😉

Do you want our Puppet setup to burn? 😄

That's why I suggested a major release! 🙂

But on the other hand... We haven't switch to Puppet 7 yet, so it might take another half decade to switch to Puppet 8 😄

but I guess it could also be configurable??

Sure 🙂 I'm also happy to change our enc code in case this might be really breaking in Puppet 8 🙂 In the end it's probably just a revert 😄

Maybe it's easier to just create an

enc

function?

Can't follow, sorry 🙈

I'm thinking that's something I could do in a module without needing anything to change in core Puppet.

it could be $trusted['enc'] as well

think about the environment, keep the global namespace clean :)

Not sure if I could actually limit it to variables that came from the enc though. But might be a nice way to document where the variable comes from in my manifests. eg. writing

enc('tier')

instead of

$::tier

which might be a fact or from the enc)

I do prefer $trusted['enc']

puppetserver already has support for $trusted and also for embedding data from scripts executed in the puppetserver, that's almost like an ENC

so I think it makes sense to have ENC data in $trusted as well

(also I think https://puppet.com/docs/patterns-and-tactics/latest/integration/integration-with-external-data-providers.html#trusted-external-command is totall underrated)

and largely unknown

Node scope is also a pain. My role/tier etc. are actually set in site.pp inside

node

definitions, so have to be accessed as

$role

$tier

etc. It's not clear when glancing at code that they're not coming from the local scope, and they're definitely not top scope, so

$::role

is wrong.

that sounds like an odd/interesting pattern

ewoud - https://puppet.com/docs/patterns-and-tactics/latest/integration/integration-with-external-data-providers.html#fact-terminus sounds like a better way of getting facts in to Foreman than the inotify stuff in Foreman's enc script? (for users who aren't actually using Foreman as their ENC)

afisher: yes, but the challenge is that you can only have one fact terminus and puppetdb also wants to be one

so you end up subclassing the puppetdb and hacking it, but if you don't want puppetdb you need to implement another class too