FAQ
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.

How's hiera involved in that? You now have $test as an uninitialized local
variable (no longer a class parameter). It expands to nothing when you
interpolate it into your filename, so you're managing File["/tmp/"], which
is equivalent to File["/tmp"]. That file (directory) already exists, and
that's all you ask Puppet to ensure, so Puppet does nothing.
Wow. That totally makes sense. I was under the impression (very likely a
mistaken impression apparently) that puppet would look at $test, not find
anything in it, and then do look up in hiera for the full scope of the
variable (aka: class::variable -> testhiera::test). So this explains that
some of the "oddity" i've seen is just a misunderstanding of the
documentation. Thanks for pointing that out!

On Thursday, October 9, 2014 9:36:38 AM UTC-5, jcbollinger wrote:
$bar = hiera('myfoo::bar', 'defaultvalue')
However, the puppet docs basically say do this for 2.7 but not for 3+
[ https://docs.puppetlabs.com/hiera/1/puppet.html ].
In Puppet 2, that was the only way you could do it. After Puppet 3 was
released, it was common for module authors to attempt to support both P2 and
P3, which tied them to that form. Even with official support for the P2
series ending, there is probably still interest in compatibility from some
quarters.

As for using only automatic parameter binding in P3, that's basically a code
style argument, its position right in the documentation notwithstanding. The
advice is not bad as far as it goes, but do note that it also presents an
apparently acceptable (albeit downplayed) alternative: explicitly document
the hiera keys your class uses. It seems like you've probably been around
enough to see a code-style war or two, so I'll leave it there.
OK. So it isn't going to cause me problems, it is just backwards
compatibility and/or a code style choice. Then in that case, I may start
using it just so that I have it explicitly called for my own use when I
look at the code in 6 months. :-)


[snip]
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).
Class parameter defaults do not interfere with automated data binding.
Puppet's automated test suite verifies this, so if you're seeing different
behavior then there is some sort of local modification or environment issue
that is causing breakage. I hope you'll forgive me if I judge it more likely
that your tests are misleading you.
No worries. I get it. Chances are much more likely I goofed something up. I
just don't know what. :-)

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. 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.
It seems like you may have a misconception: automated data binding applies
specifically to class parameters, as an aspect of resolving their
values. It
does not apply to class variables that are not parameters, and it is not
automagically applied to parameters of classes that have not yet been
evaluated.
Your code (2) is dangerous for one of two reasons:

If the code is written as you intended, then it relies for a class parameter
default on a class variable of a different class, without doing anything to
ensure that that other class (hieratest) has been evaluated. You can find
extensive discussion of this issue and others related to using other classes'
variables for parameter defaults by googling "puppet params class pattern".
If you meant to write "class testhiera ( $test = $testhiera::test )", then
you are specifying the default value for class parameter $teshiera::test to
be itself. In that case, that default value will be used only in
situations
where it has not been intialized, so I think it's functionally equivalent to
"class testhiera ( $test = undef )".

Either way, your code will work fine as long as the hiera lookup for your
class parameter succeeds (so that the default value is not consulted). It's
what will happen when the lookup accidentally or intentionally fails that may
come back to bite you in the assets.
The second case was my intent, and that might explain a lot of the
behaviour I have seen.

I have plans for tonight, but I am going to try hacking on hiera again this
weekend. Fingers crossed I can make good progress in understanding hiera.
:-)

Thank you for your help on this!
~Stack~

--
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/f6a59e5f-e254-479c-a189-a6d6f1963444%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 11 of 16 | next ›
Discussion Overview
grouppuppet-users @
categoriespuppet
postedOct 8, '14 at 1:44p
activeOct 14, '14 at 7:50a
posts16
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase