On Thu, Mar 12, 2015 at 06:32:21AM -0700, jcbollinger wrote:
> On Wednesday, March 11, 2015 at 8:57:00 AM UTC-5, Christopher Wood wrote:
>
> (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?
>
> 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?
> 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.
>
> Well Hiera doesn't offer either, so your sanity is safe.
>
> Seriously, although hiera_array('my::key') does return an array value,
> that does not necessarily mean that hiera('my::key') will do so too.
> Neither function says "the data for 'my::key' is an array". The latter is
> not looking up the same thing as the former, and again, that's the
> problem. Puppet should need only to know the key, not which type of
> lookup to use.
>
> 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.
> > 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.
>
> Each user of the data (generally a Puppet class or defined type) has to
> know whether he is supposed to use an ordinary priority lookup, an array
> lookup, or a hash-merge lookup for each key, because the value retrieved
> has the intended content only if the correct form of lookup is used.
> Generally speaking, the value obtained via a different form of lookup has
> little, if any, significance. It's not a question of choosing which one
> you want for a particular purpose, but rather of divining which is the
> (only) one appropriate for the data.
> People run into this issue in practice when they try to use automated data
> binding with data set up for array or hash-merge lookup.
>
> 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/dce8db40-d48c-452c-8b7b-edaec89f56b5%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/dce8db40-d48c-452c-8b7b-edaec89f56b5%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/20150313171151.GB18053%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.
