On Thursday, April 30, 2015 at 12:10:19 PM UTC-5, Joseph Swick wrote: > > On 30/04/15 09:30, jcbollinger wrote: > > > <trim of summary of heira lookups> > > > > Priority lookup is Hiera's focus and default, and automated data binding > > uses that mode exclusively. If you want hash-merge lookup then you must > > call hiera_hash() explicitly in your manifest. > > > > > > John > > > > John, >
provisioning). Our hiera config is set for deeper merges. And that's relevant only when you are performing hash-merge lookups. > The behavior > I expect is that I should be able to set common entries items for both > server's "mysql::server::override_options:" parameter hash at a lower > heira level and put the server specific override options at the host > specific level. And you can. And that should do what you want when you perform a hash-merge lookup to retrieve the data. > However, how automatic data bindings work it only takes > the highest priority hash. > > Yes. That's what I just finished telling you. Automated data binding uses only priority lookups, not hash-merge lookups. [...] > The above is what I would expect the deeper merge to work like and I > think the original poster has this same issue. But what I have to do is > duplicate the hash from "mysql::server::override_options:" into both > servers, as in my above example, the only setting that gets applied due > to the priority lookup without hash merging is the server ID. > > Yes, that's one viable alternative. > Since it's the Official Puppet Labs MySQL module, I'm not going to go > and change every hash parameter in the module to a hash lookup function, > because it would probably break something else. That's up to you. I can't say I blame you. Sometimes you have only bad alternatives. > So I deal with the work > around of unnecessary duplication of data in hiera and try to let > everyone I work with know of this limitation for hash lookups and > automatic data bindings when working with 3rd party modules. > > It's not a limitation of hash-merge lookups, nor of lookups of values that happen to be hashes. Perhaps I wasn't clear:* the fact that a particular key in your hiera data happens to have a hash as its associated value does not imply and is not meant to imply that a hash-merge lookup should be performed to retrieve that value*. You get a hash-merge lookup *only* via the hiera_hash() function. The issue was first characterized as a limitation of automated data binding, but it is better characterized as a limitation of Hiera's built-in back ends. Which type of lookup to use (at least by default) should be a characteristic of the data; it should not be the responsibility of the data consumer to guess which type of lookup to use. > We certainly can (and do) use an explicit hiera_hash() lookup in some of > our own internal modules, but this results in inconsistent behavior due > > to the limitations of the automatic databindings. I'm not following what's inconsistent about getting hash merge lookups when you request them, and not when you don't. I can understand wishing that you *could* request them (or better: not need to request them) for automated data binding, but that's not a consistency issue. > The hiera issue is > the only reference to it I could find when I first started looking into > what was going on and why I wasn't getting the results I expected. It's > even mentioned in the hiera documentation: > > > https://docs.puppetlabs.com/hiera/1/lookup_types.html#deep-merging-in-hiera--120 > > > I'm not sure what you're trying to say there. Yes, hash-merge behavior is described in the hiera docs. That's relevant when you request a hash-merge lookup. Not so much when you request a priority lookup, whether explicitly or implicitly. 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/8ac6996c-a334-4ce2-9d41-ff10989fea74%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
