Puppet users - Dec 2011 - explicit class dependencies

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.

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.
>
> +1
We 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.