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+unsubscr...@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.
