> Hiera allows you to lay out your data in two dimensions: data file and > key. Whatever selection rules you want to use to choose particular data > need to operate in that context. There are at least three ways in which > you can embed additional dimensions: > > 1. You can create separate hierarchies or hierarchy pieces based on > node data, by interpolating the data into the hierarchy definition file > 2. You can use compound keys > 3. You can expand your values into hashes (with the hash keyspace > constituting an additional dimension) > > Would you mind going into detail on options 2 and 3?
> Those can be used separately or in combination, and even in > self-combination, so in principle, you can use as many dimensions as you > want. In practice, it can get very messy, very quickly. > Getting messy, quickly is my concern if the hierarchy is not the best fit for the enterprise or the enterprise architecture changes. Are there any rules of thumb to consider that would suggest hiera is not the best data externalization tool and someone might be better off with a RDMS or denormalized search index as the external data source? -- 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/-/uiYolhQxbgsJ. 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.
