Do explicit class dependencies work?
This simple example fails with:
Could not find resource ''Class[Config]'' for relationship on
''Class[Uses_config]''
class config {
}
class uses_config {
Class[''config''] ->
Class[''uses_config'']
}
include uses_config
Am I doing something?
Thanks,
Christian
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Tue, Dec 6, 2011 at 12:27 PM, Christian G. Warden <cwarden@xerus.org> wrote:> Do explicit class dependencies work? > This simple example fails with: > Could not find resource ''Class[Config]'' for relationship on ''Class[Uses_config]'' > > class config { > } > > class uses_config { > Class[''config''] -> Class[''uses_config''] > } > > include uses_config > > Am I doing something?You didn''t declare include class config. If you intend uses_config to automatically include class config, you should declare it there. In either case you are missing include config or class { config: } somewhere. HTH, Nan -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Dec 06, 2011 at 01:38:38PM -0800, Nan Liu wrote:> On Tue, Dec 6, 2011 at 12:27 PM, Christian G. Warden <cwarden@xerus.org> wrote: > > Do explicit class dependencies work? > > This simple example fails with: > > Could not find resource ''Class[Config]'' for relationship on ''Class[Uses_config]'' > > > > class config { > > } > > > > class uses_config { > > Class[''config''] -> Class[''uses_config''] > > } > > > > include uses_config > > > > Am I doing something? > > You didn''t declare include class config. If you intend uses_config to > automatically include class config, you should declare it there. In > either case you are missing include config or class { config: } > somewhere.Thanks, Nan. Sorry, I got a little overzealous in trying to come up with a minimal example. Here''s the problem I was actually trying to troubleshoot: class config { $x = ''abc'' } class uses_config { Class[''config''] -> Class[''uses_config''] $x = $config::x } include uses_config include config This results in: warning: Scope(Class[Uses_config]): Could not look up qualified variable ''config::x''; class config has not been evaluated I think it''s similar to the problem I asked about with tags in another thread. If I include config before uses_config, I don''t get an error. Christian -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Dec 6, 4:12 pm, "Christian G. Warden" <cwar...@xerus.org> wrote:> On Tue, Dec 06, 2011 at 01:38:38PM -0800, Nan Liu wrote: > > On Tue, Dec 6, 2011 at 12:27 PM, Christian G. Warden <cwar...@xerus.org> wrote: > > > Do explicit class dependencies work? > > > This simple example fails with: > > > Could not find resource ''Class[Config]'' for relationship on ''Class[Uses_config]'' > > > > class config { > > > } > > > > class uses_config { > > > Class[''config''] -> Class[''uses_config''] > > > } > > > > include uses_config > > > > Am I doing something? > > > You didn''t declare include class config. If you intend uses_config to > > automatically include class config, you should declare it there. In > > either case you are missing include config or class { config: } > > somewhere. > > Thanks, Nan. Sorry, I got a little overzealous in trying to come up > with a minimal example. Here''s the problem I was actually trying to > troubleshoot: > class config { > $x = ''abc'' > > } > > class uses_config { > Class[''config''] -> Class[''uses_config''] > $x = $config::x > > } > > include uses_config > include config > > This results in: > warning: Scope(Class[Uses_config]): Could not look up qualified variable ''config::x''; class config has not been evaluated > > I think it''s similar to the problem I asked about with tags in another thread. > If I include config before uses_config, I don''t get an error.Indeed, it is at least partially a parse order issue, and it looks like you may be confusing that with application order. Class and resource relationships, such as those declared via the arrow syntax in your example or via the ''require'' family of resource metaparameters, govern the order in which resources are applied to nodes. That has very little to do with the order in which manifest files are processed by Puppet. The relationship you declare in your example does not cause class ''config'' to be included on the node, nor its manifest to be parsed. It only specifies that class ''config'' must be applied to the node before class ''uses_config'', which is pointless in this simplified example. Class ''uses_config'' needs class ''config'' to already have been parsed, however, and you example does nothing to make that so. For influencing parse order you have three functions: ''import'' (which you shouldn''t use except in certain special cases such as site.pp), ''include'', and ''require''. The ''import'' function processes one or more manifest files explicitly. The ''include'' and ''require'' functions both assign the specified class to the current node, autoloading and processing its manifest first, if necessary. The ''require'' function additionally establishes a relationship between the requiring class and the required one, of just the type that your example creates via the arrow syntax; in other words, it declares both types of dependencies in a simple statement. Generally speaking, if one class references variables of another class then the first class should ''include'' the second, or posibly ''require'' it if that''s appropriate. If it cannot do so (because the latter class is parameterized, for instance) then you have an extra burden to ensure that classes are declared and/or ''include''d in an order that works. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Christian G. Warden
2011-Dec-07 23:01 UTC
Re: [Puppet Users] Re: explicit class dependencies
On Wed, Dec 07, 2011 at 01:36:13PM -0800, jcbollinger wrote:> On Dec 6, 4:12 pm, "Christian G. Warden" <cwar...@xerus.org> wrote: > > On Tue, Dec 06, 2011 at 01:38:38PM -0800, Nan Liu wrote: > > > On Tue, Dec 6, 2011 at 12:27 PM, Christian G. Warden <cwar...@xerus.org> wrote: > > > > Do explicit class dependencies work?[...]> > Here''s the problem I was actually trying to > > troubleshoot: > > class config { > > $x = ''abc'' > > } > > > > class uses_config { > > Class[''config''] -> Class[''uses_config''] > > $x = $config::x > > } > > > > include uses_config > > include config > > > > This results in: > > warning: Scope(Class[Uses_config]): Could not look up qualified variable ''config::x''; class config has not been evaluated > > > > I think it''s similar to the problem I asked about with tags in another thread. > > If I include config before uses_config, I don''t get an error. > > Indeed, it is at least partially a parse order issue, and it looks > like you may be confusing that with application order.Thanks, John. This explanation is very helpful. Indeed, I''ve been having trouble understanding what happens during the parsing/compiling stage.> Class and resource relationships, such as those declared via the arrow > syntax in your example or via the ''require'' family of resource > metaparameters, govern the order in which resources are applied to > nodes. That has very little to do with the order in which manifest > files are processed by Puppet. The relationship you declare in your > example does not cause class ''config'' to be included on the node, nor > its manifest to be parsed. It only specifies that class ''config'' must > be applied to the node before class ''uses_config'', which is pointless > in this simplified example. Class ''uses_config'' needs class ''config'' > to already have been parsed, however, and you example does nothing to > make that so.At least part of my confusion is the use of imprecise language in the documentation. For example, this example from the language guide''s section on qualified variables[1]: class myclass { $test = ''content'' } class anotherclass { $other = $myclass::test } "Variable qualification is dependent on the *evaluation order* of your classes. Class myclass must be evaluated before class anotherclass for variables to be set correctly." (emphasis added) The term, evaluation order, is not used anywhere else in the language guide. Does it refer to parsing, compiling, instantiation, or configuration, to use the terms from the puppet internals[2] documentation?> For influencing parse order you have three functions: ''import'' (which > you shouldn''t use except in certain special cases such as site.pp), > ''include'', and ''require''. The ''import'' function processes one or more > manifest files explicitly. The ''include'' and ''require'' functions both > assign the specified class to the current node, autoloading and > processing its manifest first, if necessary. The ''require'' function > additionally establishes a relationship between the requiring class > and the required one, of just the type that your example creates via > the arrow syntax; in other words, it declares both types of > dependencies in a simple statement.The parameterized classes documentation[3] is also confusing. It states that "you should explicitly state your class''s dependencies inside its definition using the relationship chaining syntax" and explicitly declare your required parameterized classes "in your outermost node or class definitions", which is what I tried to do in my example.> Generally speaking, if one class references variables of another class > then the first class should ''include'' the second, or posibly ''require'' > it if that''s appropriate. If it cannot do so (because the latter > class is parameterized, for instance) then you have an extra burden to > ensure that classes are declared and/or ''include''d in an order that > works.This statement from the parameterized classes documentation[3] obscures the limitation in the language you identify above: "For those who prefer implicit declaration, we''re working on a safe way to implicitly declare parameterized classes, but the design work isn''t finished at the time of this writing." It suggests that it is only an aesthetic issue, but it really means that there is currently no way of declaring a parameterized class multiple times like you can (implicitly) do with ''include''. The style guide explicitly discourages having one class declare another[4]: "*Classes should generally not declare other classes.*" (emphasis in original) And the language guide says order doesn''t matter[1]: "Puppet language is a declarative language, which means that its scoping and assignment rules are somewhat different than a normal imperative language. ... Order does not matter in a declarative language." I hope this doesn''t come off as too much of a rant. I''m a big fan of puppet (even more so in the past couple weeks as I''ve started using it with vagrant), but there''s definitely room for improvement in the documentation. Perhaps the puppet glossary[5] should be featured on the documentation section of puppetlabs.com, and existing documentation should be reviewed for consistency with the glossary. Christian 1. http://docs.puppetlabs.com/guides/language_guide.html#variables 2. http://docs.puppetlabs.com/guides/puppet_internals.html 3. http://docs.puppetlabs.com/guides/parameterized_classes.html#site-design-and-composition-with-parameterized-classes 4. http://docs.puppetlabs.com/guides/style_guide.html#general-philosophies 5. http://projects.puppetlabs.com/projects/1/wiki/Glossary_Of_Terms -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 12/07/2011 06:01 PM, Christian G. Warden wrote:> On Wed, Dec 07, 2011 at 01:36:13PM -0800, jcbollinger wrote: >> On Dec 6, 4:12 pm, "Christian G. Warden"<cwar...@xerus.org> wrote: >>> On Tue, Dec 06, 2011 at 01:38:38PM -0800, Nan Liu wrote: >>>> On Tue, Dec 6, 2011 at 12:27 PM, Christian G. Warden<cwar...@xerus.org> wrote: >>>>> Do explicit class dependencies work? > [...] >>> Here''s the problem I was actually trying to >>> troubleshoot: >>> class config { >>> $x = ''abc'' >>> } >>> >>> class uses_config { >>> Class[''config''] -> Class[''uses_config''] >>> $x = $config::x >>> } >>> >>> include uses_config >>> include config >>> >>> This results in: >>> warning: Scope(Class[Uses_config]): Could not look up qualified variable ''config::x''; class config has not been evaluated >>> >>> I think it''s similar to the problem I asked about with tags in another thread. >>> If I include config before uses_config, I don''t get an error. >> Indeed, it is at least partially a parse order issue, and it looks >> like you may be confusing that with application order. > Thanks, John. This explanation is very helpful. Indeed, I''ve been > having trouble understanding what happens during the parsing/compiling > stage.See https://projects.puppetlabs.com/issues/10972. What''s even cooler is if you try (at least on my 2.6.2 installation) to evaluate that with puppet agent rather than puppet apply, you get no error at all. $config::x will evaluate to undef, which will happily interpolate into a string as "". So if you have this: file { "$config::x/somefile.conf": ... } now all your files are created in /. Hooray! You are not alone in being frustrated in this behavior. The documentation is self-conflicting and the language semantics aren''t actually what they say they are. When the docs say the language is "declarative" (which doesn''t really have much meaning), they usually also say something about order not mattering. Order not mattering is a property of purely functional languages, and many clearly declarative languages are purely (or mostly so) functional. The problem is that puppet can''t actually be purely functional, because it isn''t a single assignment language. Sure, the obvious case of reassigning to the same variable in the same scope isn''t allowed, but what about the non-obvious cases, like: - class inheritance - collection overrides (Foo <| |> { ... }) - parameterized classes vs. "include" As it turns out, these are the places where single assignment really helps one reading the code reason about it. It''s quite easy to see the order of assignments and interactions between multiple lines in the same file. It''s much more difficult to absorb the ordering and interactions between components that live in different files, or even different modules. Yet, it''s these far-reaching reassignments that are allowed, while the short-range, easily understood ones (simple $foo=bar) are the ones that are forbidden. Go figure. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Dec 7, 5:01 pm, "Christian G. Warden" <cwar...@xerus.org> wrote:> I hope this doesn''t come off as too much of a rant.As a person who is frequently critical of some of the newer Puppet features -- especially parameterized classes -- I wouldn''t have much standing to object to your criticisms. I would suggest, however, that you consider filing issue tickets against the documentation for some or all of your complaints. The sqeaky wheel gets the grease, and formal issue tickets squeak far louder than complaints in this forum.> I''m a big fan of puppet > (even more so in the past couple weeks as I''ve started using it with vagrant), > but there''s definitely room for improvement in the documentation. Perhaps the > puppet glossary[5] should be featured on the documentation section of > puppetlabs.com, and existing documentation should be reviewed for consistency > with the glossary.Sounds good to me, but as a practical matter, it is likely that specific documentation issues will be fixed a lot sooner than a general documentation review such as you describe will be performed. On the other hand, the more documentation issues are open, the more likely I predict Puppetlabs will be to try to sweep many of them up at once with some kind of general review / rewrite. Oh, and since you mentioned PuppetLabs''s style guide, I''ll tell you that I don''t care for it (the latest version) at all. It is focused on a style that caters to pervasive use of parameterized classes, and as far as I am concerned, parameterized classes should be considered harmful. If you''re mostly or completely avoiding parameterized classes then the apparent reasons for many of the style recommendations, including some you touched on, just fall apart. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 12/08/2011 04:44 PM, jcbollinger wrote:> I would suggest, however, that > you consider filing issue tickets against the documentation for some > or all of your complaints. The sqeaky wheel gets the grease, and > formal issue tickets squeak far louder than complaints in this forum.+1 Better yet, fork the puppetdoc github repo and fix any obvious issues yourself, and if uncertain, ask via issue tracker what the correct wording/description should be. I''ve found that the puppetlabs team likes pull requests ;-) Cheers, Felix -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Dec 13, 2011 at 04:29, Felix Frank <felix.frank@alumni.tu-berlin.de> wrote:> On 12/08/2011 04:44 PM, jcbollinger wrote: > >> I would suggest, however, that >> you consider filing issue tickets against the documentation for some >> or all of your complaints. The sqeaky wheel gets the grease, and >> formal issue tickets squeak far louder than complaints in this forum. > > +1We love tickets. They mean we actually pay attention, and that we can''t forget. ;)> Better yet, fork the puppetdoc github repo and fix any obvious issues > yourself, and if uncertain, ask via issue tracker what the correct > wording/description should be. > > I''ve found that the puppetlabs team likes pull requests ;-)Totally. You are absolutely encouraged to fix things up. Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.