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
this:
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.
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 [email protected].
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.
