On Wednesday, September 17, 2014 10:55:12 PM UTC-5, François Lafont wrote:
>
> Thank you for your answer.
>
> Le 17/09/2014 17:12, jcbollinger a écrit :
>
> >> class my_module (
> >> $var1 = $my_module::params::var1,
> >> $var2 = $my_module::params::var2,
> >> ) inherits my_module::params {
> >>
> >> include my_module
> >>
> >
> >
> > There's no point to including class my_module inside its own definition.
>
> > Did you mean to include my_module::internal?
>
> Yes exactly. Sorry for the mistake.
>
> >> class my_module::internal {
> >>
> >> file { '/tmp/test_internal.txt':
> >> content => template('test/test_internal.txt.erb'),
> >> }
> >>
> >> notify { 'm1': message => "var1 = ${my_module::var1}", }
> >> notify { 'm2': message => "var2 = ${my_module::var2}", }
> >> notify { 'm3': message => "foo1 = ${my_module::foo1}", }
> >> notify { 'm4': message => "foo2 = ${my_module::foo2}", }
> >>
> >> }
> >>
> >> It's curious because I use no inheritance in my_module::internal,
> >> no require etc. and despite that I can access to the variables of
> >> my_module. Is it normal?
> >>
> >>
> >
> > It is very poor form to access $my_module::params::foo1 and
> > $my_module::params::foo2 via inheriting class my_module (i.e. as
> > ${my_module::foo1}, etc.).
>
> But the my_module::internal inherits no class, so doesn't inherit
> my_module class? I don't see where is the inheritance in the code
> above.
>
>
Sorry, I worded that very poorly.
Class my_module inherits my_module::params. Absent my_module declaring its
own local variables $foo1 and $foo2, the inheritance results in variables
$::my_module::params::foo1 and $::my_module::params::foo2 being accessible
unqualified in class my_module's namespace. Because those variables are
accessible unqualified in class my_module, they are also accessible
elsewhere qualified by namespace my_module (i.e. $::my_module::foo1) --
*that* little bit of evil should not be used. Instead, always qualify
variable references with the namespace in which the variable is actually
declared (my_module::params in this case).
> Or, if I understand well, when I have:
>
> class my_module {
> include my_module::internal
> }
>
> I can say: "my_module::internal" inherits my_module. Is that correct?
>
>
No, not at all. My apologies for the confusion.
>
> > With that out of the way, it is better to say
> > that the result you observe is among the valid possibilities than to say
> it
> > is "normal".
> >
> > All class variables have global visibility regardless of inheritance or
> > declaration (e.g. via include / require).
>
> Do you mean that with:
>
> class my_module {
> include my_module::internal
> }
>
> In the body of my_module::internal class I can access to the variables
> defined in my_module class? With a unqualified name?
>
No, not in the slightest. I mean that if class my_module::params has a
local variable with unqualified name "foo1", then that variable can be
referenced from any class in any module as $my_module::params::foo1,
regardless of any inheritance or include / require / contain statements
anywhere. Under some inheritance-related circumstances it can also be
referenced in certain places via its unqualified name, but as a matter of
form, it should be accessed only via its qualified name anywhere outside
class my_module::params.
The main role of inheritance and the only role of include / require /
contain with respect to class variables is as I described before:
> > The main purpose of all that *as
> > it pertains to variables* is to ensure that Puppet evaluates classes
> during
> > catalog compilation in an order that assigns values to those variables
> > before those values are used. It also serves a documentary purpose,
> > showing clearly that one class has a dependency on another.
> >
> >
> >
> >> One thing very curious too: in the my_module::internal class
> >> I can access to $var1 with this syntax :
> >>
> >> ${my_module::var1}
> >>
> >
> >
> > No, you can't. There is no $var1 in class my_module::internal, so you
> are
> > not accessing such a variable. You are instead accessing
> > $my_module::params::var1 via an alias (that alias resulting from class
> > my_module inheriting my_module::params). Don't use that alias, even in
> > class my_module.
>
> Ok.
>
No, not ok, my apologies. There is after all a $my_module:var1 -- it is a
class parameter. I overlooked that this is a different case from the
$my_module::foo1 case discussed above. So, it's right and fine to refer to
$my_module::var1 if that's what you actually mean.
>
> >> and $var1 is empty. Ok, I think I understand that. But in my
> >> template "test_internal.txt.erb" I can use directly:
> >>
> >> blabla <%= @var1 %> blabla
> >>
> >> without the fully qualified name. Here, I don't understand.
> >>
> >
> >
> > I don't believe you.
>
> I can give you a precise and quick (if you have already a Debian Wheezy)
> process to reproduct this. I take a Debian Wheezy, updated and cleaned
> (it's a simple VM in Virtualbox). And here is the process:
>
>
I'm not prepared to set up and run this test, but if it genuinely produces
the results you describe then that demonstrates a bug. Here are the docs
on Puppet scope:
https://docs.puppetlabs.com/puppet/3/reference/lang_scope.html. Here are
the docs on referencing variables from templates:
https://docs.puppetlabs.com/guides/templating.html#referencing-variables.
Inasmuch as this is one of the more heavily used areas of Puppet, I suspect
that something else is going on in your environment, but if such a bug has
indeed cropped up then I'm sure PuppetLabs would appreciate a bug report.
> # And here is the result of my template.
> root@wheezy-clean:/etc/puppet/environments# cat /tmp/internal.txt
> # Class test::internal
> var1 = specific_value_var1 <---------- Here!!!
> var2 = default_value_var2
> foo1 = value_foo1
> foo2 = value_foo2
>
> root@wheezy-clean:/etc/puppet/environments# cat /tmp/test.txt
> # Class test
> var1 = specific_value_var1
> var2 = default_value_var2
> foo1 = value_foo1
> foo2 = value_foo2
> -------------------------------------------------------------------
>
> I have:
>
> var1 = specific_value_var1
>
> in the /tmp/internal.txt file but in my template internal.txt.erb
> I use :
>
> var1 = <%= @var1 %>
>
> Did you have the same result? I don't understand and for me it's
> not logical.
>
> Another curious thing: even if I put:
>
> $var1 = "internal"
>
> in the test::internal class, the /tmp/test.txt don't change.
>
>
Puppet does perform some caching that could perhaps explain a (short-lived)
failure to track such a change. You can restart the master process to
forcibly flush all caches, and you can configure the cache timeout to zero
to disable caching (not effective for master processes that are already
running). If your result still does not reflect the local $var1 then I
think that's a pretty good sign that what's happening is not what you think.
> > That form of reference would work of class
> > my_module::internal were inheriting my_module::params (or class
> my_module)
> > because of the aliasing mechanism I described. It would also work if
> > my_module::internal had a parameter or an ordinary variable of its own
> > named "var1". It will not work with the code you actually presented.
>
> I understand. But in this case, where is my error in the
> commands above?
>
>
I cannot explain the template result you described. As I said, it might
reflect a new Puppet bug, but I think it's more likely that for some reason
the manifests you are looking at are not the ones from which your machine
is being configured. That might be a caching issue, or it might arise from
something else specific to your environment.
> I will continue to think about your long answers (thank you again
> for the help). For starters, I would like to known where I'm
> wrong in the example above. Maybe I'm very tired and I missed something
> simple and stupid.
>
>
For what it's worth, you are asking good questions and performing
appropriate experiments. When something I'm trying looks right but doesn't
work, the problem is almost always something simple (and sometimes
stupid). We all have those moments.
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/bf022dd3-8971-444d-b1c5-78de50a0a6ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
