On Monday, December 8, 2014 5:26:05 AM UTC-6, Poil wrote: > > Hey thanks, > > I don't understand : in template we can use "classes" that contain all > defined classes. >
That is potentially misleading: the <https://docs.puppetlabs.com/guides/templating.html#access-to-tags-and-declared-classes> 'classes' <https://docs.puppetlabs.com/guides/templating.html#access-to-tags-and-declared-classes> variable <https://docs.puppetlabs.com/guides/templating.html#access-to-tags-and-declared-classes> can give you all classes that have been declared *up to that point* in the course of evaluating manifests to build the target node's catalog. There is no way to reliably get a list that correctly anticipates all classes that ultimately will be present in the final catalog, and it is very difficult to predict the the order in which classes will be added, so 'classes' is far less useful than it may sound. Even if you find that it works as you want for some nodes, with your current manifest set, it is extremely difficult to ensure or prove that it will work as you want for all nodes as your manifest set evolves. When it fails, it will fail silently. > Is it a good idea to add > > if defined(Class['::apache']) { > require apache; > include collectd::apache > } > > No, it is a terrible idea. The 'defined()' function <https://docs.puppetlabs.com/references/3.4.stable/function.html#defined> has the same kind of evaluation-order dependency that templates' 'classes' variable has. It should *never* be used to check whether classes or resources have been declared, and in fact there has been serious consideration of deprecating that aspect of its behavior. You can use defined to test whether a class or resource type is *available* to be declared, but that requires a different form for the argument. Moreover, whether a class is available is a static characteristic of your manifest set, so it is of comparatively little value to test that dynamically. > Or is a class is like other ressource, only defined when parsed ? (so > could be randomly defined when playing collectd::autoconfig) > > The terms "defined" and "declared" are rather slippery here, and the 'defined()' function unhelpfully conflates their different meanings. A resource *type* is "defined" if Puppet knows that type, either because it is a plugin type that is available to the catalog builder (built-in or from a module), or because it is a defined type whose definition has been evaluated or can be located by the autoloader. Similarly, a class is "defined" if its definition (body) has been evaluated or can be located by the autoloader. The use of 'defined()' to test these conditions is not dangerous or harmful. On the other hand, a "resource" in the sense of an instance of a given resource type comes into existence only when Puppet evaluates a declaration of it. Before completion of catalog building, it is impossible to predict which additional resources will be declared during the remainder of the catalog building process. Similarly, a defined class will be present in the target node's catalog only after Puppet evaluates a declaration of it (an 'include', 'require', or 'contain' call, or a resource-style class declaration). Before completion of catalog building, it is impossible to predict which additional classes will be declared during the remainder of the catalog building process. People who are unfamiliar with these details are prone to suppose that 'defined()' can inform about *all* the classes and/or resources in the final catalog, but that is impossible. Parser functions are called as part of catalog building, and the desired information is not available until catalog building is complete. > For the moment I've invert my code > I have a class apache::collectd which call collectd::apache with an hash > as parameter > > If that does the job you want it to do then it's fine. You risk trouble with it, however, if class collectd::apache is declared anywhere else. If you use a resource-style class declaration (as you must to specify any class parameters via your manifests) then that class declaration must be the *first* declaration of that class that is evaluated (else catalog building will fail). We have already covered that evaluation order is difficult to predict. If you have multiple declarations of a given class, then it is difficult to control the order in which they are evaluated. If you need to dynamically determine which classes to declare, then the general solution is to decouple that determination from Puppet's evaluator: use an ENC or hiera to tell Puppet which classes are needed, and what their parameters 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/77e7727d-40dc-481b-a095-0c7f822155c6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
