On May 9, 2010, at 1:08 PM, Nigel Kersten wrote:
On Sun, May 9, 2010 at 11:53 AM, Markus Roberts
<[email protected]> wrote:
I think from the bracketing text:
Defined types can also use metaparameters, for instance we can use
‘require’ inside of a definition. We can reference the values of
those metaparameters using built-in variables. Here’s an example:
....and:
> The above is perhaps not a perfect example,...
...that the intent of the example is to show what you can do
(reference metaparameters as if they were variables) rather than
what you should do. Perhaps what's needed is a more compelling case
of why you might actually want to access metaparameters inside a
defined type, and then just ditch the existing example?
Primarily I think that the intro language tutorial shouldn't go into
any of this at all, and should just show "yes, you can use
metaparameters on defined types too".
I just can't think of a defined type situation right now where you
absolutely want the require on the internal native type rather than
on the encapsulating defined type that couldn't be handled with
internal relationships?
Nope. And currently one is turned into the other on the client, so
they're actually equivalent. Like I said, dumb example.
I also don't understand how the plusignment operator works in this
situation. ie:
define d_exec() {
exec { $title:
...
require => Foo[bar],
}
if $require {
Exec[$title] { require +> $require }
}
}
Why doesn't this work? Shouldn't you be able to append to the
require? If not, what's the point of using the plusignment operator
rather than just doing:
Because you're defining and modifying a value in the same scope, which
at various points I've been convinced isn't declarative, therefore is
an error. Given that Puppet's language at best resembles a
declarative language rather than entirely completely being one (at
least until Markus gets the futures done), this is duct tape rather
than a real feature.
define d_exec() {
exec { $title:
...
require => $require,
}
}
It's tough to talk about this clearly.
The thing that makes a metaparameter meta is that it models something
that all resources share, which almost always means that some aspect
of the framework does the modeling.
In the case of 'require', the two examples are exactly equivalent in
0.25.x, because we've worked hard to make them equivalent (other than
the fact that your first example is a compile error).
Really, you should only ever care about the metaparam thing if a given
metaparam actually means something ot the resource type in question.
I used to think this was a feature, but Markus has convinced me that
in general it's a bug - e.g., 'alias' on hosts. So, this whole thing
should probably just be removed, except that it can sometimes cause
some weirdness if you a) want to name a param something that conflicts
with a metaparam or b) try to use a variable name that conflicts with
a metaparam name.
Really, it's b) that should have a warning. The following code
probably does not behave as you expect:
define foo {
$require = Yay[ness]
file { '...': ... }
}
This results in the file getting 'require' set to Yay[ness].
And in fact, setting any variable named after a metaparam in a class
or defined resource type will set that metaparam on all contained
resources (and, I think, on the class/defined resource).
This is probably a bug, and it's certainly an artifact of the
implementation, but it's still true.
--
I have a switch in my apartment... It doesn't do anything. Every once
in a while, I turn it on and off. One day I got a call... It was from
a woman in France... She said, "Cut it out!"
-- Stephen Wright
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
