On Wednesday, November 19, 2014 3:55:15 AM UTC-6, Steven Post wrote: > > Hi, > > So if I understand correctly, I can use 'null' as a value, and it will be > used instead of the value somewhere lower on the hierarchy? >
YAML 1.2 defines the (unquoted) token "null" to be a scalar value representing the same (no)thing as Ruby nil. A YAML parser that doesn't doesn't understand that will take that token as a scalar representing the four-character string "null". I don't happen to know which way Hiera goes, which might in fact vary with the underlying version of Ruby, but either way, null is a value of some kind. When you perform a "deeper" hash merge you should find that corresponding hashes at different levels of your data hierarchy are merged, where "corresponding" is defined with respect to nested hashes according to the chain of keys required to drill down through the data to each hash. In such a merge, you should find that the (key, value) pairs from the higher-priority level are retained, and where the hash from the lower-priority level has keys that do not appear in the higher level hash, those keys and their associated values end up in the merged result. > If that is the case, my problem is solved (I think). Completely preventing > the nonsensical stuff is not the goal here, but it should be possible in > hiera to avoid it by being able to remove already set options. > > Hash merging always results in a hash whose key set is the union of the key sets of the merged hashes. The value associated with each key is the question, and with hiera the questions are 1. Whether nested hashes are merged at all (vs. hashes appearing as values in higher-priority levels completely replacing lower-level values), and 2. If nested hashes are merged, which value appears in the result for keys that appear in both original hashes. At this time, those questions can be answered only globally in the Hiera configuration or, to some extent on a whole-lookup basis via explicit lookup functions (hiera() vs hiera_hash()). That is a recognized flaw in Hiera, in that the appropriate form of lookup is (should be) a characteristic of the data, not of the query. With that said, I don't think YAML is not a particularly good vehicle for expressing data that must carry such fine distinctions, so I suspect that the current limitations will be with us for a long time. > I can indeed modify the consumer of data as well, but since this is > already used in production, I need to be a bit careful with the changes I > do. > I don't know if our setup already supports yaml 1.2, our hiera version > currently is 1.3.1 > You're missing my point there, I think: if you modify the form of the data, then almost surely you *must* modify the data consumer. How else will it know what to do with your modified data structure? > > I'll test this out and get back with my findings. > > I look forward to hearing how it turns out. 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/74aed43c-159c-4903-83ff-efc3fbbbc20d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
