On Nov 2, 9:57 am, Baptiste Grenier <baptiste.gren...@gmail.com>
wrote:
> Hello,
>
> Le 31/10/11 16:09, jcbollinger t l scripta :
>
>
>
>
>
> > On Oct 28, 10:07 am, Baptiste Grenier <baptiste.gren...@gmail.com>
> > wrote:
>
> > > I am trying to define the modules' run order like this:
>
> > You are running up against a common source of confusion: the
> > difference between order of manifest evaluation (on the master) and
> > order of catalog application (on the client). You appear to be
> > conflating the two into "run order", but in general there is no need
> > for them to be the same, and indeed, one sometimes wants them to
> > differ.
>
> > Evaluation order affects (only) the compilation of your manifests into
> > a catalog, and the key mechanisms available for influencing it are
> > (1) the 'require' and 'include' functions (*not* the 'require'
> > resource metaparameter), and
> > (2) lexical order within individual manifest files
>
> > Application order affects (only) the order in which resources are
> > applied to your nodes, but that's irrelevant if catalog compilation
> > fails. The user-accessible mechanisms for influencing it are
> > (1) the 'require' resource metaparameter and its friends,
> > (2) the arrow syntax for defining resource relationships,
> > (3) run stages, and
> > (4) the 'require' function (which also affects order of manifest
> > evaluation)
>
> Thanks for all this information, I will do some more tests to see if I
> can achieve my goal (see next paragraph).
>
> > You have an evaluation order problem, and you have tried to fix it by
> > constraining the application order. Instead, you want something like
> > this:
>
> > [...]
>
> > class sudo {
> > # KEY CHANGE:
> > include "aptdater::client"
>
> The problem is that I want to be able to include the sudo class without
> including the aptdater::client class: some node can have sudo managed,
> but won't be configured for apt-dater.
There are several ugly ways you could do this. The clean way would be
to pull the $aptdater::client::sudo_allow_aptdater_user variable out
to a separate class that both class sudo and class aptdater::client
can safely include (which implies that it is not parameterized), or to
global scope, or to external data loaded in both places via
extlookup() or hiera. If you're using an ENC then global scope is a
good bet; otherwise external data is probably better. The separate
class option is great, but it is distinct from the other two only if
the new class can choose the variable's value based only on nodes'
facts.
> I could perhaps use a parametrized class like with something like an
> aptdater_client_enabled paramter, but I don't find this very nice...
> It's why I am trying to test a variable to see if aptdater::client is
> enabled.
It constitutes a class dependency for one class to rely on data
belonging to another. If the former class must not directly or
indirectly 'include' the latter, then it is inconsitent to have such a
dependency at all. Similarly, it is always a poor idea for a class to
depend on whether a separate class has been included, which is the
most fundamental data belonging to that class.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
