On Monday, September 22, 2014 11:18:55 AM UTC-5, Mike Reed wrote:
>
> Hey Nan and John,
>
> Thank you both for the replies and insight into my questions below; they
> are most helpful and very much appreciated.
>
> Based on your answers, I have few other questions that occurred to me:
>
> In response to my question about inherits, John had mentioned this below:
> "If you don't need the variables of the params class for class parameter
> defaults, however, then you can replace inheritance with 'include'ing (or
> 'require'ing or 'contain'ing) the params class it the start of erstwhile
> child class's body."
>
> In my example config.pp, I'm using things like "$puppet_config_path =
> $::puppet::params::puppet_config_path," which obviously points to my
> params.pp file and thus would in theory, pull the variable value and
> evaluate accordingly.
>
I'm not quite sure what you mean by that. It sounds like you may have the
misapprehension that upon encountering a reference to a class variable,
Puppet ensures that the variable's class has already been evaluated. That
is not the case. The future evaluator apparently catches cases where the
variable's host class has not been evaluated yet, but it is not safe for it
to autodeclare the class at that point.
> If I am indeed pointing these local variables to my params.pp, it
> doesn't seem obvious that I need any include or inhert to params.pp in my
> subclasses. In this example, I do indeed need the variables from my params
> class for my subclass defaults but because I'm specifically calling these
> with the use of local variables, is it advisable to still "include" the
> params.pp subclass? It seems that my manifests would be more tidy if I
> didn't have include/inherits littered throughout my subclasses.
>
Why do you think the *use* of which you put the other-class variables has
anything to do with the requirements for accessing them in the first
place? Your classes puppet::config and puppet::service *should* inherit
from puppet::params because they use its variables for their own parameter
defaults; that way they are better self-contained. If they do not do so
then they make every one of their users responsible for ensuring that
puppet::params is evaluated first. If these classes are intended to be
private to your module then you can make that work, but it's still worse
form.
>
> Further, if I had a selector or case statement in my params.pp, they it
> would seem appropriate to "include" params.pp in my config.pp because I
> indeed do need that selector/case statement to be evaluated before the
> config.pp subclass can be completed. Am I thinking about this correctly?
>
>
Yes and no. The presence specifically of a selector or case statement in
puppet::params doesn't really factor in. You use that class's variables,
and you need the class itself to have been evaluated before you do. Again,
*that
is the point of inheriting from it* in this context. Declaring it via
"include" etc. (or via a resource-like class declaration) would also have
that effect, but would not ensure puppet::params is evaluated soon enough
for its variables to be used as class parameter defaults. In your case, it
is actually sufficient for class puppet to 'include' puppet::params before
puppet::config and puppet:service, provided that the latter two are never
declared by anyone else, but if you are going to use the params class
pattern then you ought to do it right.
Understand, too, that 'include' et. al. are *declarations* of the specified
class(es). The statement "include 'foo'" has very nearly the same meaning
as "class { 'foo': }". It tells Puppet that class 'foo' must be included *in
the catalog*, not in the current manifest. Any given class will be
evaluated at most once, so "include 'foo'" is a no-op if class "foo" has
already been evaluated (this is a very valuable feature). Its 'require'
and 'contain' brethren always have their effects on class relationships,
but their class-evaluation aspect is also a no-op for classes that have
already been evaluated.
Also, do not confuse resource-like class declarations with resource
references to declared classes. You can apply chain operators to both,
even mixed, but you will cause yourself grief if you use a declaration
where you really wanted a reference. Your class 'puppet' suffers from that
issue.
> Lastly, it seems that in the case of any module with subclasses, I want
> and need to include class/subclass ordering or the sake of ordering
> sanity. In your opinion, should I be including subclass ordering in my
> init.pp for each module I write (assuming it includes subclasses)?
>
>
You should declare class relationships where there are genuine
order-of-application constraints. You should avoid them otherwise. The
nature of the classes is irrelevant.
I would rewrite your class 'puppet' like so:
init.pp
----
class puppet {
# Managing puppet consists of first managing its config,
# then managing the Puppet service.
contain '::puppet::config'
contain '::puppet::service'
Class['::puppet::config'] -> Class['::puppet::service']
}
>From what I can see, your classes puppet::config and puppet::service are
already just as they should be.
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/b28c7de7-4b07-49c2-a7a6-ab11e36b7449%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
