Puppet Community

it depends :slightly_smiling_face:
You can add a variable to a class like $package and in hiera you have different hierarchies per OS and you define the parameter in each hierarchy

or you check the OS and include a different class per OS

default should be fail(“not supported”) :-D

I was trying to do this but without the include, just do it straight in the class, which was making it complex, thanks for highlighting that

It can also help to take advantage of the fact that a `package` resource's `$title` doesn't have to match its `$name`. For instance, you could do
```package { 'foo-devel':
   ensure =&gt; installed,
   name =&gt; 'foo-dev',
}```
And then refer to that resource by `Package['foo-devel']` everywhere without having to know the particularities of the underlying OS.

Yeah, I’d say you need few os-specific profiles to setup things and then use OS hiera layers to lookup for a package names e.g.

most imortant: you dont have to deal with yum or dnf or apt. package resource handles this by itself.

<@UQ70FTGMC> the old blog post about where to put data can be useful <https://www.puppet.com/blog/hiera-data|https://www.puppet.com/blog/hiera-data>

I would just say it does depend on how many OS you intend to do. I would always recommend doing it simplest way you can first and refactoring if it does become more complicated later.

I can see a mistake I was making already, I was trying to do it in the class, rather than in hiera

its that thing of if there's not that much data its simpler just to do it directly in the class like Tims example. If it starts feeling complex to do in the class then it could well be time to look at hiera.

the examples don't take that into account, and so my own experience was conflicting with the options / suggestions from examples

Are there any know issues with Puppet DSL functions and catalog compilation isolation? We have a customer (PE) who has config flapping between cluster nodes.

is this considered a legacy fact usage?
include "editor::${::kernel}" ?

so what would be the right format for that ?

Being a legacy fact shouldn't affect format BUT the "best practice" way of using a fact these days is using the $facts array

IF you have to put it in a string like that... then...

but accessing it via topscope is deprecated

I think I've just assumed at this point that if its not part of a structured fact it must be legacy lol, I've had to change so many of them in our code.

yea, thats where i am at rychannel.
trying to get a catalog compilation in my ci/cd on 8.1, and def having a go at it.

so this would be proper supported replacement:
include "editor::${facts['kernel']}"  ?