Hi John, thanks for your answer and your examples.
2018-05-21 16:09 GMT+02:00 jcbollinger <[email protected]>: > 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 [email protected]. 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.
