Hi,
Le 19/09/2014 17:36, jcbollinger a écrit :
> The main points I am trying to get across
And I thnink that you have succeeded now. ;)
> are these:
>
> 1. References to *non-local* variables should always be performed via
> qualified names, even when class inheritance makes the variable in
> question
> accessible also via its unqualified name.
> 2. All qualified names used should accurately reflect the location of
> the referenced entity's declaration (some variables have multiple,
> distinct
> qualified names).
> 3. If a class or defined type refers to a variable belonging to a
> different class then it should ensure via 'include' / 'require' /
> 'contain'
> or via class inheritance that the variable is initialized first.
It's very clear. Thanks.
> I am not saying that references to variables declared *locally* should use
> qualified names, but if you want to adopt that practice then it's fine.
>
> With respect to other classes' variables, though, I seem not to be
> successfully communicating point (2).
Now I have understood the 3 rules.
>> I use $::test::xxx in class::internal not $::test::params::xxx
>> because when xxx is "var1" or "var2", I want to have the value of
>> var1 and var2 given as parameters of the test class (I don't want
>> the default value of var1 and var2).
>>
>
>
> Yes, that's fine for var1 and var2, but not for foo1 and foo2 which are not
> declared by class test. I don't see any particular purpose for foo1 and
> foo2 to live in test::params anyway, however, if they are not to be used as
> class parameter defaults. You could as easily put them directly in class
> test, and then continue to refer to them as you are now doing.
Yes, it's good idea.
Finally, as regards your comments, I think follow this pattern where I follow
your 3 rules, it seems ;):
-----------------------------------------------------
# Example of declaration for the "test" class.
class { test:
var1 => 'specific_var1',
}
#### test module with its classes ####
class test::params {
# API of the module with the default values.
$var1 = 'default_var1'
$var2 = 'default_var2'
}
# The *main* class of the module
class test (
$var1 = $::test::params::var1,
$var2 = $::test::params::var2,
) inherits test::params {
# Shared variables in all classes of the module.
$foo1 = 'value_foo1'
$foo2 = 'value_foo2'
include ::test::internal
# Here, I could use $var1, $var2, $foo1, $foo2
# (only in the main class of the module).
notify { 'v1': message => "var1 = $::test::var1", }
notify { 'v2': message => "var2 = $::test::var2", }
notify { 'f1': message => "foo1 = $::test::foo1", }
notify { 'f2': message => "foo2 = $::test::foo2", }
# etc.
}
class test::internal {
# It's an internal class of the module test which will be
# never called by the "user". So, the line below is useless.
# It's just for self-documenting.
# Maybe I could remove this line, I don't know...
require ::test
notify { 'iv1': message => "Internal var1 = $::test::var1", }
notify { 'iv2': message => "Internal var2 = $::test::var2", }
notify { 'if1': message => "Internal foo1 = $::test::foo1", }
notify { 'if2': message => "Internal foo2 = $::test::foo2", }
# So, in templates, I use the syntax scope['::test::var']
file { '/tmp/internal.txt':
content => inline_template("var1=<%= scope['::test::var1'] %>\nfoo2=<%=
scope['::test::foo2'] %>\n"),
}
}
-----------------------------------------------------
> By the way, don't be confused about the meaning of the 'include' statement,
> or its siblings 'require' and 'contain'. 'Include' says that the named
> class must be included *in the catalog*; it does NOT interpolate the named
> class's body in place of the include statement (i.e. it is not analogous to
> a C preprocessor #include directive). A given class can be the subject of
> any number of 'include', 'require', and 'contain' statements; no class will
> appear in the catalog more than once.
Yes, it's clear and even clearer with your link below.
> In part, it looks like you are running into bug 1220
> <https://tickets.puppetlabs.com/browse/PUP-1220>.
Yes, this is exactly my problem!
> That was reported fixed
> in Puppet 3.5.0, but if I understand correctly, you need to enable the
> future parser to actually activate the bug fix (which would make the
> variable reference in your template fail to resolve in both cases).
I confirm. If I put:
parser = future
in the puppet.conf (in [main] section), I have the expected behaviour.
To my mind, the execpted behaviour (explained in the puppet documentation)
occurs with "parser = future" which is *not* enabled by default.
It's curious, but not a problem for me. I guess it's a backward
compatibility problem...
>> And in this case, I don't understand. I thought that :
>>
>> $var1 = "value_var1" # LINE A
>> include ::test::internal # LINE B
>>
>> and
>>
>> include ::test::internal # LINE B
>> $var1 = "value_var1" # LINE A
>>
>> was completely equivalent. Am I wrong?
>>
>>
>
> Yes, you are wrong, but the reason is a bit subtle. For a comprehensive
> explanation, see
> http://puppet-on-the-edge.blogspot.com/2014/04/getting-your-puppet-ducks-in-row.html
Thanks for this link which I read and read again. Very interesting.
This link has helped me to understand a lot of things in Puppet.
For intance, it's too simple to say "puppet is declarative".
No, this is not exact. There a phase, the evaluation of manifests
and the building of the catalog where puppet is deeply imperative.
Very interesting...
> both at the same time. You really ought to consider externalizing your
> data and accessing via Hiera.
I will ;) ... but not in module, only in "profiles" as explained in the
link below:
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
I don't want Hiera lookups in modules but only in profiles.
I have really learned a lot of things in this thread. Sincerely
thank you for all your long and detailed explanations. Although
I have cut lot of quotes of your messages, I have really read
everything very carefully.
Thank you again for your help. :)
François Lafont
--
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/5420017E.1080208%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
