On Thursday, August 16, 2012 4:08:26 PM UTC-5, Alexander Swen wrote: > > >> I hadn't thought of just separating that information into its own YAML >> file, that's an interesting solution and one I'll definitely be looking >> into to. >> >> But then, information about one host is kept in multiple files and it > would be my aim to wrap all specific info for one host into one yaml. so > that once you remove the host, you only have to remove that file. >
As much or as little information about the hosts as is wanted can be put in the one big hash, so host information does not need to be split up. If everything went into one hash then removing info for a host would involve removing one block of lines from one file. That's only a little less convenient than removing a single file, and it could be automated relatively easily. Please understand that I don't have any stake in what approach Daniele chooses. I am not advocating for a particular approach, nor asserting it superior over any other that also achieves the desired result, but I do hope that Daniele and others who may read this thread will base their decisions on solid reasoning. > That yaml file should keep alle the specific params of that host. and > every other module should be able to take advantage of that information. > This is not only the case for dhcp, but for dns as well. and of course the > /etc/network/interfaces file of the host itself. > > And to avoid needless redundancy of information, certain values should be > written into that file maximum once. so, the ipaddress for example must not > be written in some dns config yaml file as well. and in the hostname.yaml. > Should you decide to change the ipaddress, you definitely forget either the > bind or the dhcp config. > Certainly data duplication should be avoided, and that could be aided by putting all information for each host into a single hash for that host. Those per-host hashes could equally well (for this purpose) appear in separate YAML files or all together as values in a larger hash in one YAML file. > > I realize that this might lead into a feature req for Hiera. > There must simply be a way to tell the dhcp and bind modules to have a > look in all hostname.yaml files to collect all ipaddresses and macaddresses > and hostnames. > > I suppose you're suggesting another function similar to hiera_hash(), in that it provides the result in the form of a hash that associates the data from each yaml with a key that corresponds to the filename. Hmm, where did I see such a data structure described before? Inasmuch as you can achieve the output you want now, by structuring your data the way you want it in the first place, I think this is by no means a must-have feature. If the mode of file organization you describe would be of such high value to you, however, then Hiera supports pluggable back-ends, so you can easily add that capability. You could probably get 80% of the way there by deriving your custom back-end from the current YAML back-end. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/lsYFiVADptYJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
