On Wednesday, December 10, 2014 9:24:44 PM UTC-6, 巨海录 wrote:
>
> # ntp/manifests/init.pp
> class ntp (
> $var_01 = '/etc/ntp.conf',
> $var_02 = 'ntp/ntp.conf.erb',
> ) {
> include ::ntp::params
> include ::ntp:install
> }
>
>
Is "::ntp:install" just a typo? It looks like it should be
"::ntp::install" (two colons between "ntp" and "install").
> # ntp/manifests/params.pp
> class ntp::params {
> $var_03 = 'no.3'
> $var_o4 = 'no.4'
> }
>
> # ntp/manifests/install.pp
> class ntp::install {
> notify {"var_01 == ${ntp::var01}": }
> notify {"var_01 == ${ntp::var02}": }
> notify {"var_03 == ${ntp::params::var_03}": }
> notify {"var_04 == ${ntp::params::var_04}": }
> }
>
> # site.pp
> include ntp
>
> and i run this cmmand:
>
> puppet apply site.pp
>
> how puppet program parser these code in order?
>
> because sometime i can't get the correct value of var_03 and var_04. and
> they would all be nil.
>
With what you have actually written (modulo the typo I called out) you
should never see the values of $ntp::params::var_03 or $ntp::params::var_04
not yet defined in ntp::install. However, small changes in your manifests
or in the starting manifest you apply could make a difference. For
example, reversing the order of the 'include' calls in class ntp would
result in the variables not yet being defined when class ntp::install is
evaluated (when starting by evaluating class 'ntp'). Either way, starting
the evaluation at class 'ntp::install' will result in none of those
variables having been defined.
There are really two different cases here:
Case 1: Since class 'ntp::install' depends on variables of class
'ntp::params', it is wise for 'ntp::install' to start by 'include'ing
'ntp::params'. It is safe for both 'ntp' and 'ntp::install' to do that.
If that is done then class 'ntp::install' will always see initialized
values for the variables of class 'ntp::params'; otherwise, it relies on
'ntp::params' to have been evaluated at some other class's direction before
'ntp::install' is evaluated.
Case 2: The variables of class 'ntp' are different because class
'ntp::install' is declared by class 'ntp'. It is unwise, and may not do as
you expect, for class 'ntp::install' to create an evaluation-dependency
loop by declaring class 'ntp'. Puppet would not loop infinitely, but you
could get unexpected results. If 'ntp::install' must depend on variables
(including class parameters) of class 'ntp', and class 'ntp' must declare
class 'ntp::install', then the only good solution is to document that class
'ntp::install' is an internal class that must not be applied directly or
declared by classes outside its module. *Inside* the module, it probably
should be declared only by class 'ntp', but another class that can be
certain that class 'ntp' has already been evaluated could conceivably
declare 'ntp::install', too.
With that said, if you want all the gory details then I don't know any
better explanation than Henrik's
<http://puppet-on-the-edge.blogspot.com/2014/04/getting-your-puppet-ducks-in-row.html>
.
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/6a1022f2-9b84-4470-8a9a-aaef88587630%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
