(Replying to two people in one email, hum.) On Wed, Mar 11, 2015 at 06:01:39AM -0700, jcbollinger wrote: > On Tuesday, March 10, 2015 at 9:59:41 PM UTC-5, Bostjan Skufca wrote: > > On Monday, 9 March 2015 14:45:38 UTC+1, Christopher Wood wrote: > > On Sun, Mar 08, 2015 at 11:55:03AM -0700, Bostjan Skufca wrote: > > With hiera: > > - How would you go about when certain nodes need data merged from > all > > scopes, but other nodes need data from just the last scope? > > I've usually had a "classname::merge: true" key in hiera, controlling > whether I use hiera() or hiera_hash() to obtain the data I need. > > And this hits the nail on the spot, even if unknowingly:) > The problem I am seeing here and which I am only now being able to > articulate, is the clash of two contradictory elements: > 1. Puppet development is pushed towards decoupling code (manifest) from > data, a noble goal > 2. Puppet provides two functions, hiera() and hiera_array(), and the > very existence of more than one function to retrieve data destroys the > notion, that code should be unaware of underlying data storage details.
I rather take your point, but isn't the requirement for different data handling just another data item? 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. I'm not really sure there's a way to automagically distinguish "this is an array, do not retrieve its contents from all levels" "this is an array, do retrieve its contents from all levels" while still preserving our sanity. (I've had some nasty run-ins with merging lookups and have decided they're mostly not for me, maybe the smarter people on this list are having better results.) > Puppet in fact provides three functions functions for lookups: there is > also hiera_hash(). > > In any case, you are quite right. Which sort of lookup is intended is an > attribute of the data -- part of the definition of each key -- but it is > not represented in or alongside the data. Each user of the data somehow > has to know. That could be tolerated, inconvenient as it is, except that > it is incompatible with automated data binding. This is an issue that has > been recognized and acknowledged, though I'm uncertain whether it is > actively being addressed. Could you possibly expound on the "Each user of the data somehow has to know" part? I'm having trouble with the notion that people would use puppet manifests and hiera data without knowing what's in them. > 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 [1]puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > > [2]https://groups.google.com/d/msgid/puppet-users/24d78255-435a-480a-94be-128a0e760c45%40googlegroups.com. > For more options, visit [3]https://groups.google.com/d/optout. > > References > > Visible links > 1. mailto:puppet-users+unsubscr...@googlegroups.com > 2. > https://groups.google.com/d/msgid/puppet-users/24d78255-435a-480a-94be-128a0e760c45%40googlegroups.com?utm_medium=email&utm_source=footer > 3. https://groups.google.com/d/optout -- 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/20150311135651.GA841%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
