Re: [Puppet Users] Re: explicit class dependencies
On Tue, Dec 13, 2011 at 04:29, Felix Frank 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: explicit class dependencies
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: explicit class dependencies
On Dec 7, 5:01 pm, "Christian G. Warden" 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: explicit class dependencies
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" 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 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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
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" 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
> > > 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
[Puppet Users] Re: explicit class dependencies
On Dec 6, 4:12 pm, "Christian G. Warden" 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
> > 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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
