Retrieving Hiera arrays from init.pp

[Jeremiah Jester]

I've been able to retrieve data from hiera via init.pp from a basic variable. However, when i try and pull an associative array from hiera, I'm unable to get the data. I've verified that my yaml syntax is correct by running hiera via the command line:

*hiera yaml file

log_special::log_vars:
    a: - 'jklkl'
       - 'test'

*heira via cmd line
[jjest@puppet-master-t1 templates]$ hiera log_special::log_vars hostname=puppet-client-t1
{"a"=>["jklkl", "test"]}

 
Anyone know how to pull and parse this from init.pp? Precise code would be helpful.

Thanks,
JJ

[Chad Huneycutt]

I'm pretty sure we need more information than that.

1. Is puppet using the proper hiera.yaml? The command line client at
least used to use a different config than puppet (/etc/hiera.yaml vs
/etc/puppet/hiera.yaml). It sounds like you have this right, if you
are able to pull basic variables from your data files.

2. Are you sure that hiera is not working? What have you tried, and
what happened when you tried it?

Have you looked at http://docs.puppetlabs.com/hiera/1/index.html ?
There are examples there.

- Chad

> --
> 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...@googlegroups.com.
> To post to this group, send email to puppet...@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Chad M. Huneycutt

[Jeremiah Jester]

Chad,

Thanks for the reply. I am using /etc/puppet/heiradata for the
location of all my hiera files.

[root@puppet-master-t1 puppet]# ls hieradata/
defaults.yaml global.yaml groups hosts

Referencing non hashed/array variables from init.pp works. However, I
cannot get the array variable $log_status2 - it is being returned as a
string. I've included a snip of my init.pp file with comments to give
more details. I've looked at the limited hiera docs included the one
you sent, I'm clearly doing something wrong.

Appreciate the help.
JJ

class log_special
(
#log_special::log_vars: "test"
$log_vars=log_vars,

#log_special::log_vars2:
# b: 'fdsa'
# c: 'fdsaaaa'
$log_vars2=hiera_hash('log_vars'),
$log_vars2=$log_vars2['b']
)
{
exec{"log_vars": command=> "/bin/echo '${log_vars}'", logoutput=>true;}
#Debug: Executing '/bin/echo 'test'
exec{"log_vars2": command=> "/bin/echo '${log_vars2}'", logoutput=>true;}
#Debug: Executing '/bin/echo 'bfdsacfdsaaaa''

> You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/3A5F9Wh6RdY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.

[Chris McDermott]

I'm confused at your snippets because they don't seem right. For instance, you show:

#log_special::log_vars: "test"
$log_vars=log_vars,

But that doesn't look syntactically correct... I'm pretty sure that would fail to compile.

Anyway, I think if this really is what your yaml looks like:

log_special::log_vars:
    a: - 'jklkl'
       - 'test'

Then in your pp manifest, you'd want to have something like this:

$log_vars = hiera_hash('log_special::log_vars', false)

if ($log_vars) {

  $array = $log_vars['a']

}

And then $array should be an array containing 'jklkl' and 'test'.

Chris

[jcbollinger]

On Tuesday, September 24, 2013 11:07:59 PM UTC-5, mcd wrote:

I'm confused at your snippets because they don't seem right. For instance, you show:

#log_special::log_vars: "test"
$log_vars=log_vars,

But that doesn't look syntactically correct... I'm pretty sure that would fail to compile.

I think that's ok; Puppet allows bare words as string literals.  The code declares the default value of class parameter $log_speciall::log_vars to be the string 'log_vars'.
 

Anyway, I think if this really is what your yaml looks like:

log_special::log_vars:
    a: - 'jklkl'
       - 'test'

Then in your pp manifest, you'd want to have something like this:

$log_vars = hiera_hash('log_special::log_vars', false)

Well, often you would want to use the ordinary hiera() function rather than hiera_hash().  The fact that the value is expected to be a hash is not directly relevant here.


John

[jcbollinger]

On Thursday, September 19, 2013 1:12:22 PM UTC-5, Jeremiah Jester wrote:

class log_special
(
#log_special::log_vars: "test"
$log_vars=log_vars,

Note that Puppet 3's automatic data binding will result in the value associated with key 'log_special::log_vars' being bound to parameter $log_vars here.  The default value will be used only if there is neither an explicit binding via the class declaration nor a value obtainable from hiera.  The value will be obtained from hiera via the plain hiera() function, but this will provide a hash if that's in fact the data type present in the data.

 

#log_special::log_vars2:
#    b: 'fdsa'
#    c: 'fdsaaaa'
$log_vars2=hiera_hash('log_vars'),

That's ok, but of questionable utility.  Also, only in those data-dependent cases where hiera_hash() may return a different value than hiera() does is it sensible.  Those cases involve the value being present at multiple levels in the data hierarchy.

 

$log_vars2=$log_vars2['b']

That is broken, however.  You cannot declare the same parameter name twice (I'm surprised that Puppet does not diagnose it), plus, parameter default values cannot safely refer to other parameters of the same class, regardless of the order of the parameter list.

 

)
{
  exec{"log_vars": command=> "/bin/echo '${log_vars}'", logoutput=>true;}
  #Debug: Executing '/bin/echo 'test'
  exec{"log_vars2": command=> "/bin/echo '${log_vars2}'", logoutput=>true;}
  #Debug: Executing '/bin/echo 'bfdsacfdsaaaa''

And those are also at least somewhat broken, as interpolating a hash into a string (the 'command' parameters) will cause it to be flattened.  Therefore, you cannot determine from the result whether the variable that was interpolated was originally a string, or whether it was something else.  Supposing that you produced the output by declaring the class something like this

class { 'log_special':
  log_vars => 'test'
}

, and that the data are as you described in comments in your second post, the output looks reasonable.  I would say "looks as I would expect" if not for the weird extra appearance of $log_vars2 among the class parameters.


John