On Monday, June 17, 2013 12:28:18 AM UTC-5, Robin Powell wrote: > > This seems to come up for me a lot. As an example, my Hiera data > includes both hypervisors and the VMs that they contain. It would > be very useful to have the VMs say "I'm a VM on host X" and, in > templates in host X, be able to say "What are all my VMs?". >
It is inherently non-idiomatic for your templates (or manifests) to pose such a question, or really any question. Rather than asking a question, the templates may need to say "my VMs are [...]". I know I'm being nit-picky with the wording, but people really need to get a firm grip on the concept in order to master Puppet. > > Doing this via storeconfigs rather defeats the purpose of my Hiera > tree, which is to be the single source of truth. > I think you're focusing on the wrong thing when you say that. To the extent that it's applicable to the problem, storeconfigs is simply the infrastructure that makes exported resources work. It is in no way an independent source of truth, because everything in it comes from declarations made in one manifest or another, based on node facts and possibly on data from some other source. Put another way, in its application to problems of this kind, storeconfigs serves merely as an asynchronous communication channel. Focusing on exported resources, then, these are simply a mechanism for making declarations during the compilation of one node's catalog that can later be incorporated by reference into any node's catalog. Such declarations draw on whatever source(s) of truth you choose, and no others, just like any other declarations your manifests make. Collecting exported resources later does not introduce any new sources of truth. > > The way I'm currently doing it is to have a script that collates all > my Hiera host data into a special YAML file, and then have templates > read that YAML. > > So you in fact *don't* have a single source of truth currently. Not any more so than you would have with exported resources, at least. Your collation script and special YAML file simply take the place of master-mediated resource export and the storeconfigs database, respectively. Perhaps you have other reasons to want to avoid storeconfigs, but otherwise I cannot imagine why you think what you've come up with is superior to using exported resources. > I'm wondering if there's a better/more correct/more idiomatic way to > engage in this sort of referential linking across the Hiera tree? > > It depends in part on whether you intend to extend your single-source-of-truth requirement to include DRY requirements on your hiera data. One possibility would be to provide indices in your hiera data -- for example, for each VM host, an array of the names of its VMs. That's not DRY, however, if it duplicates information in VMs' individual data files. If you want all needed data stored in hiera, with no redundancy and no use of intermediate collation, then all the data need to be provided to (at least) all the associated nodes; that is, to the VM host and all its VMs. They all need to get all the data, else there is no escaping a need for some kind of data duplication. You might find it convenient and logical to structure it as one large, complex, nested value, from which the individual components would select the pieces they need. For example, a hash with VM hostnames as keys, and hashes of VM names to VM parameter hashes as values (i.e. a trebly-nested hash). Alternatively, there are ways you could spread out the data over multiple Hiera keys, but the overall logical structure is going to be similar. It should be obvious at this point is that with this kind of data structure, you are not going to be able to use automated class parameter binding to assist in declaring most of the various interrelated bits and pieces. Given those choices, I would probably opt for exported resources, myself. 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
