On Thursday, October 9, 2014 5:23:39 PM UTC-5, Stack Kororā wrote:

Wow! Thanks for the responses John!
On Thursday, October 9, 2014 8:52:00 AM UTC-5, jcbollinger wrote:
If the master had successfully looked up your datum then the result would
have been as you expected. The behavior you present is characteristic of
(and well documented for) the case where the automatic lookup fails,
leaving the master to fall back to the default value given in the class
definition. The problem is not in your Puppet manifests, and your CLI
tests demonstrate that it is not in your data themselves, but those are not
the only possibilities.
If it isn't hiera and it isn't puppet, what other possibilities are there?
Any idea on how I can debug this better? I would love to see in the puppet
logs something like "found a variable with no definition, looking up in
hiera in this file...nope didn't find it...trying this other file...ah
found it" but I haven't seen anything on how to better troubleshoot /how/
puppet is determining if a variable is in hiera or not.

I said the problem is not your *data*, but that doesn't cut Hiera out of
the picture completely.

One possibility would be that the agent is using a different hiera
configuration than you access from the command line, so even though your
data are ok, the agent is not consulting them. Since you now have hiera
lookups apparently working (at least to some degree), we can probably
reject that as an explanation for any remaining issues (but you may want to
verify which issues do remain).

The main other category of possibilities I see is file access issues. It
is not an error for an hiera data file for any hierarchy level to be
missing or inaccessible: if for any reason hiera cannot read the data file
nominated for some hierarchy level, then it just moves on to the next
hierarchy level. Even if the agent runs as root, there can still be access
controls (e.g. SELinux policy) that prevent it from reading certain files
that can be read by commands you launch directly from a shell.

1.2) class myclass ($parameter_one = "default text") { ...content =>
$parameter_one, ...}
[...] will /always/ go to 'default text' for me. It has yet to pull
back the
hiera data.
If that's true then something is dreadfully wrong in your environment.
Hrm...that's not good. But this test VM is a very new build of Scientific
Linux 6.5 with the latest puppet. I really haven't made many changes. Not
sure what I could have goofed on it. Any suggestions for debugging what is
wrong? I mean nothing is really being kicked out in the log files (but that
doesn't mean there isn't a problem).
Verify that the problem persists (you have presented conflicting data about
that). If so, turn on debug logging at the master, and see whether
anything useful turns up in its log. Also, make sure you don't anywhere
have a declaration (as opposed to a *definition*) of the class that gives
an explicit parameter value. That is, make sure you don't anywhere have

     class { 'myclass': parameter_one => 'default_text' }

2) $ cat modules/testhiera/manifests/init.pp
class testhiera ( $test = $hieratest::test ) {
file { "/tmp/$test" : ensure => present}
How is that different from your 1.2, which you say doesn't work?
Not sure i understand your question.

At (1.2) you say this doesn't work:

     class myclass ($parameter_one = "default text") { ... }

At (2) you say THIS (corrected per your response) does work:

     class testhiera ( $test = $testhiera::test ) { ... }

As far as I can tell, they are not different in any way that matters. In
particular, the reference to $testhiera::test in (2) (or anywhere else)
does not itself cause Hiera to be consulted. If you are now getting a
value drawn from your Hiera data in (2) then you should continue to get the
same value if you change that parameter's default to "default text".

The 1.2 that doesn't work I am setting a default value in hopes that the
hiera value is taken. In this example, I am explicitly calling the hiera
value...Now functionally it may be the same (or at least it is supposed to
be), but that isn't how I see it behave.

I'm having trouble believing that changing the expression of a class
parameter's default value between a variable reference and a string literal
would affect whether that parameter's value is bound via Hiera. If you can
confirm such behavior then I'm sure PL would appreciate a bug report.


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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b3a5b8f0-2f5b-454c-83e3-5c42b6f5f24e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 13 of 16 | next ›
Discussion Overview
grouppuppet-users @
postedOct 8, '14 at 1:44p
activeOct 14, '14 at 7:50a



site design / logo © 2022 Grokbase