On Wednesday, September 17, 2014 6:22:52 AM UTC-5, François Lafont wrote:
> In fact, It's curious. I have made some tests with puppet 3.7.0
> on Debian Wheezy and I can simply do this:
>
> class my_module::params {
>
> ## API of the module ##
> $var1 = default_value1
> $var2 = default_value2
>
> ## shared variables between the classes of my_module
> ## but they are not part of the API module
> $foo1 = default_value_foo1
> $foo2 = default_value_foo2
> ...
> }
>
> 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?
>
> }
>
> 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.). 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). 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.
>
> 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. 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.
>
> Anyway, although I do not understand well the "scope" mechanism
> etc. I feel that I can just use this design for inner classes :
>
> class my_module::internal {
>
> # No inheritance, no require of my_module::params etc.
> # It's unnecessary.
>
>
No, not a safe assumption.
> # In the class, I must use the fully qualified name
> # to access to a variable of my_module inherited by
> # my_module::params (and sometimes overwritten).
> # For instance:
> notify { 'm1': message => "var1 = ${my_module::var1}", }
>
>
Yes and no. Do always use fully-qualified names to reference variables of
other classes, even if you inherit from their classes. Do not reference
class variables via inheritance-related aliases, however. To some extent
those are requirements, and to some extent just good practices.
> # But in templates, I can directy use @var1.
>
>
Only if there is a global or local variable with that name in the scope
from which the template is evaluated.
> }
>
> Am I wrong?
>
>
I'm afraid so, as described already above.
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/96c0b88f-6a17-4bd4-98be-30d4b6920dbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
