On Wednesday, 11 March 2015 14:57:00 UTC+1, Christopher Wood wrote:
>
> (Replying to two people in one email, hum.)
>
> 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.
>
Yes, certain dependency always exists, that can not be denied. But it
should lean towards minimum amount of coupling.
But if we venture a peek into programming languages, for example towards
functions that return arrays, which best matches our current discussion.
function callee ()
{
...
return $arrayOfData;
}
function caller ()
{
$newDataArray = callee();
}
The caller() gets very messy, if it is its responsibility to figure out if
returned array from callee() is either:
- an array of keys and values
- an array of arrays of keys and values
This is what I am talking about - if callee just returns array of arrays it
is not behaving very nicely :)
And this is exactly what hiera does.
If I think about this a little further, this is what hiera backends do.
hiera*() functions on the other hand does a bit poor job at abstracting
provider internal data, or does a good and simple job alright sacrificing
some flexibility we had with class inheritance.
Anyhow, it seems writing custom backend providers is the way out.
> 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.
>
Agreed. But if you use hiera with multiple scopes (common, dc, row, rack,
node), each layer usually knows if data from parent scope should be merged
with, or replaced.
Again, maybe it is just that default hiera backends do not allow for such
flexibility. It should not be hard to switch that to custom provider, whose
data model actually allows for such flexibility.
(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.)
>
Care to elaborate a bit, especially how did you overcome them (define all
data for each node)?
b.
--
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/a3b26c59-beb9-4dc1-a669-e253858d602a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
