On Friday, May 18, 2018 at 7:42:10 AM UTC-5, Arnau wrote:
>
> Let me tell you what I wanted to do: I wanted to build the "classes" hash
> based on different profiles. So, insetad of writing classes for each
> profile and then "collect" them in the role in hiera:
>
> roleA.yaml
> classes:
> - profileA
> - profileB
>
> and then declaring the classes:
>
> class profileA {
> include apache
> }
>
> class profleB {
> include mysl
> }
>
>
> I wanted to do:
>
> profileA.yaml
> classes:
> - apache
>
>
> profileB.yaml
> classes:
> - mysql
>
> roleA.yaml
> custom_facts:
> - profileA
> - profileB
>
>
> then "merge" the classes hash so it pick classes for all the profiles a
> node belongs to....
>
>
> The main reason is to not having to write classes for each profile and do
> as much as I can in hiera.
> I'm not sure if my idea makes sense to you, or if I explained it properly.
> But with teh potential of hiera3 + Puppetfile I wanted to avoid writing
> puppet code as much as possible.
>
>
I think you're trying to get Hiera to shoulder a bit too much of the load.
Nevertheless, you could make a similar data structure work for you with
just a little help on the Puppet side. For example, consider this class:
class site::role_classes(Array[String] $profiles) {
$profiles.each |$profile| {
$profile_classes = lookup("profile_${profile}_classes", Array[String[1
]], 'unique', [])
$profile_classes.each |$profile_class| {
include $profile_class
}
}
}
Having that, instead of hiera_include('classes'), which seems to be what
you were aiming toward, you can instead declare
include site::role_classes
Again, you cannot expect to put your per-profile class lists into different
files at the same hierarchy level, at least with the standard YAML
back-end. You need to distinguish by keys instead. But the above is all
the manifest code you need around data that look like this:
*roleA.yaml*
site::role_classes::profiles:
- profileA
- profileB
*profile_classes.yaml*
profile_profileA_classes:
- apache
profile_profileB_classes:
- mysql
Note that only two hierarchy levels are represented there: one with a
separate file per role, defining the profiles for that role, and one with a
single file declaring all the classes for each profile. The latter
structure follows from the fact that, as you observed at the outset, most
nodes have multiple profiles.
Alternatively, if having the profile data split out into separate files is
important to you, but you insist on achieving that some other way than via
DSL code, then perhaps you would be better off writing a *bona fide* ENC
for yourself. It probably would not have to be that much more complicated
than the class above, and you then would not need any DSL code at all
outside the module-level classes.
I would be remiss, however, to fail to note that actual profile classes can
do more for you than your 100% data-driven approach can do. Profile
classes can set up relationships among the classes they declare, for
example. They can provide containment. They can 'include' other profile
classes to function as extensions. They can perform arbitrary conditional
logic to choose classes and / or class parameters. Even though you might
not usually want any of those things in your profiles, are you sure you
don't want to reserve the ability to use those and similar capabilities?
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/161ee447-a3a6-4993-a44b-0dea84457b91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
