Hi John,
thanks for your answer and your examples.
2018-05-21 16:09 GMT+02:00 jcbollinger <john.bollin...@stjude.org>:
> I think you're trying to get Hiera to shoulder a bit too much of the
> load.
>
Yes, maybe, but I wanted to take all advantages from the new hiera and
still use the old profiles/roles classes approach when needed.
> 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.
>
That's a nice approach, but, aprt from the classes, in my mind i also
wanted to have some hiera data in each profile file... but it could be
that, by mistake, i duplicate the data in two different profiles, then what
is hiera supposed to do?
> 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.
>
Too much for my approach. as i said, having hiera data in the same
hierarchy level and expect hiera to take the right decission is not
possible,
I can use the typical profile/role with hiera approach and keep putting
stuff in role and cert levels.
>
> 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?
>
Yes, I know, and i still use it, but I thought that my approach could
simplify my life for some basic cases where it's clear what the class ha to
do and has no depdency with other stuff. Clear example: autofs. If the node
has the profile "autofs" I wanted it to include the class and read data
from the profile/autofs.yaml file.
But I can put that data in other hierarchy files and move the class include
to the role level.
>
>
> John
>
> Thanks a lot for your answer,
Arnau
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAM69jx9JfMaCsh7NOVyOq7xfGyMf43qKaaQQVKnd8a4bdSVKqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
