Yeah, sounds about right. Pardon my prejudice, but from your description I get the feeling that you are not employing hiera to the height of its strengths. You want your hierarchy to contain *data* for your nodes. While it's possible to map all your resources to YAML and make heavy use of create_resources(), it is certainly not beneficial in all cases.
I suggest at least a cursory glance at the roles/profiles pattern (or what I lovingly refer to as the hiera ENC) to see if it fits you better. An approach that has served me well is to make my manifests as pseudo-intelligent as possible (allowing puppet to do the right thing without us copy-pasting all the time) and sprinkle in hiera lookups only where customization is needed or I cannot whip up a logic based on facts alone. Note that either way, you won't solve your issue of spacing out hiera values per your given design structure. If you rely on manifests more, you can get much closer to that. (If it's a sound goal at all is yet another good question.) Regards, Felix On 04/01/2014 07:10 PM, Matthew Burgess wrote: > Like I said, it was purely for cosmetic/aesthetic purposes; I wanted to > write the YAML file in the same order as things were defined in our > design document so that it was easier to review that the implementation > matched the design. Section 1 of that doc might cover something like > NTP configuraiton, which requires a package, config file and service; > Section 2 might cover sshd, again with another package, config file and > service. As it doesn't look like having multiple keys with the same > name in the same file is supported, I'll get over my obsession with > trying to lay the file out to match the order things appear in the > design :-) > > Perhaps I need to look at this another way; I could lay my tests out > (I'm sure I have some somewhere!) in the same order as the design doc, > then I get the implementation review for free by executing the tests! > > Thanks for your help, > > Matt. -- 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/533BC087.1010907%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
