but i want the variable (service_specific) available at node scope

not inside a class

you are just doing a

lookup('mysupernodevariable')

in the manifest code for nodename.test.internal?

node 'nodename ' {
 $service_specific

class { 'a' }
}

and i want to have that variable auto loaded from hiera

a lookup might work, if there is a way to reference the variable

a lookup might work, if there is a way to reference the variable

if you want data from hiera that is not part of a module's parameter namespace, then you can only use the lookup function

ok, thanks, that clears things up

ok, thanks, that clears things up

remember hiera is just a key/value store

i will probably end up wrapping the module in class, so that there is a class level variable avalible for auto lookup

generally speaking, I'm not a fan of direct hiera lookups from manifest code, it feels like the equivalent of using global variables. I'd much rather write a module and make the data a parameter to the module or make the variable a fact

agreed, lookup feel to "magic" varibable

you might look at the roles and profiles pattern

the module isnt mine, so adding a variable to the module is something i want to avoid, so i will just end up wrapping it in a class, to that there are class scope variables avalible inside the module

the module isnt mine, so adding a variable to the module is something i want to avoid, so i will just end up wrapping it in a class, to that there are class scope variables avalible inside the modules

the module isnt mine, so adding a variable to the module is something i want to avoid, so i will just end up wrapping it in a class, to that there are class scope variables avalible inside the module

If you have it as a class parameter and also need it as a separe value to lookup you can use an alias in hiera - then you only have one place to maintain that value.

If you have it as a class parameter and also need it as a separe value to lookup you can use an alias in hiera - then you only have one place to maintain that value.

thank @hbui, that is a intersting idea, but does not match how my code base is structured.

you can expose the parameters of class a that you want to allow changing and hard code the other params (or accept defaults) and then add whatever other bits are needed for making the technology that class a provides work

ya, that makes sense. Thank you

This message was deleted.

This message was deleted.

This message was deleted.

Hi Folks, How may one run eyaml more securely by passphasing (or other wise increasing the security of) the private key eyaml needs to keep next to the puppetserver (on the file system) please.

Question about performance analysis, on a non-changing windows node. transaction_evaluation @20sec, catalog_application 20sec, plugin_sync 18sec. i spend 7sec in exec, and 5sec in fact generation. I am a unique monolith include every module catalog. On linux its much much lower. Is my design just hampering me?

i should say thats in debug mode. in general my #s are half that. but wondering if i should still be striving for under 15sec total catalog application time. like is 5 sec possible?

Generally Puppet doesn't make many statements around Agent application times because it's so different between systems. The number of facts, files being applied, etc can vastly change this. For example at past job, the standard agent apply time was 120s. However that system was using Puppet as a file distribution system and needed to check 1000s of files. Most other system I've worked on tend to apply in 10-30s with 1500+ total resources. You might look into the Exec resources on your Windows machine. Possible there are more native ways to do it and you have older modules that are relying on a lot of Powershell. Or Powershell is the best way to do it and it's just ecosystem overhead for that type of resource management. fwiw, I don't think there is much value in bring apply times down from 20s to 5s.