On Friday, March 13, 2015 at 12:12:12 PM UTC-5, Christopher Wood wrote: > > On Thu, Mar 12, 2015 at 06:32:21AM -0700, jcbollinger wrote: >
> > No, it is metadata. The metadata could be lumped in with the data > the > > regular data -- and in fact, the default back end provides no other > > alternative if you want to provide that metadata at all -- but that's > > untidy, and it doesn't play nicely with automated data binding. > > > > > > > > Is any code unaware of the underlying data structure? Even if you > have a > > single type of data (plain string-like variables) your code is > > implicitly aware that it can treat them as that type. > > > > You're commingling two different concepts: the structure of the data > > provided by Hiera to Puppet, and the structure of the data in the > external > > storage on which Hiera relies. Puppet needs to know about the > former, but > > it shouldn't have to know or care about the latter. THAT's the whole > > point. The fact that there are three different Hiera lookup > functions, > > and that they can return different data for the same key -- even data > with > > different structure -- makes Puppet sensitive to the internal layout > of > > Hiera's data files. > > I grant that I'm not seeing the whole picture; I'm perfectly fine with the > notion that code/data/metadata/structure are all subsets of the information > required to correctly manage a host. I presume structure has to go > somewhere and if it's not in the pp file it's just somewhere else I will > have to know about and account for so I'm not really seeing what difference > it makes. For instance, what breaks with the current thing that wouldn't if > puppet just got data and the hiera_array vs hiera_hash determination was > made elsewhere? > > The most prominent thing that breaks is automatic data binding. If the physical layout of your data for some key is designed for service via the hiera_array() or hiera_hash() function, then you cannot use automated data binding with that key. Or to put it the other way around, if you have a class parameter whose value you want to provide via automatic data binding (as you should), then you *must* structure the associated data for for priority lookup, not for array or hash-merge lookup. In a sense, this is an encapsulation issue: the physical layout of the data is the implementation, and the keys are the interface. You shouldn't need to know anything about the implementation to use the interface, but currently, you do. > > And it would be possible. For example, the YAML back end could be > > modified to refer to an ancillary metadata file that flagged certain > keys > > for array or hash-merge lookup. That's a bit ugly, but sometimes > ugly > > happens when you have to retrofit. > > I don't know that this is better or worse than having structural > information about hiera in my pp files. I go from: > > having two places where things go (hiera and puppet) > having structural information in each (yaml anchor/alias etc., puppet data > bindings and hiera functions) > > To: > > having three places where things go (hiera, hiera metadata, puppet) > having structural information in two (yaml anchor/alias etc., hiera key > flagging) > > I've added a place and now I have more to think about, plus it's not > obvious from my puppet code where my data is coming from. and I have a lab > host where I don't actually want things tagged as merge-only to be merged > while I'm experimenting. Ouch my brain. > The design I presented was for proof-of-concept purposes. There are probably better alternatives. Even with that simple design, though, the information complexity does not increase. If you want to use any array- or hash-merge lookups *at all* then you already have to worry about manifests, data, and metadata, wherever each of those lives. The gain is in separation of concerns: when you're working with your manifests, you don't need to pay any attention to metadata, and when you're working with the data, you don't need to be worried (as much) about breaking manifests. This may even have impacted you personally, in the real-life failure case you described. I speculate that if the physical data layout had more clearly been associated directly with the data, then you would have been more likely to look for (and find) the problematic default value when you changed to hash-merge lookups. Having separate lookup functions for array- and hash-merge lookup styles can be a distraction from the fact that the physical data layout is important. It is not, in general, safe to switch from one mode to another for any given key. 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/c2110bcc-a091-4a1b-8c3e-701b30076e13%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
