Hi,
when you put it that way, it makes perfect sense indeed.
Thanks for the clarification!
On 08/26/2013 08:42 PM, Calvin Walton wrote:
> The reason is so that you can override class default values by providing
> a value with hiera. Doing any other order simply doesn't make sense for
> general u
On Fri, 2013-08-23 at 04:50 +, Igor Galić wrote:
>
> - Original Message -
> > Hi,
> >
> > is this puppet 3? I shall suppose it is.
> >
> > With the parameter name of "bar", you likely trigger the automagic hiera
> > lookup of foo::bar, which is (naturally) not done using hiera_array.
- Original Message -
> Hi,
>
> is this puppet 3? I shall suppose it is.
>
> With the parameter name of "bar", you likely trigger the automagic hiera
> lookup of foo::bar, which is (naturally) not done using hiera_array.
> Apparently, this overrides the explicit call to hiera_array.
>
>
Hi,
is this puppet 3? I shall suppose it is.
With the parameter name of "bar", you likely trigger the automagic hiera
lookup of foo::bar, which is (naturally) not done using hiera_array.
Apparently, this overrides the explicit call to hiera_array.
I'm not sure wether that's as designed, you may
Hi folks,
I just managed to reproduce on a very small scale an issue
that's I've debugged for hours yesterday.
if we have a class:
class foo (
$bar = hiera_array('foo::bar', $foo::params::bar),
) inherits foo::params {
notify{ "foo::bar: ${bar}": }
}
class foo::param