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 [email protected]. 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.
