On 2014-03-07 9:40, David Schmitt wrote:
On 2014-07-02 21:55, John Bollinger wrote:
at the point where affected resources
are declared (for Lindberg-style defaults) or at the point where the
defaults themselves are declared (for Schmitt-style defaults, if I
understand that proposal correctly).
My proposal would actually collapse those two points: the values only
affect the resources declared in the same resource block as the values
themselves. I'll explain my example more:
No defaults:
file {
"/tmp/foo":
content => 'foo',
mode => 0321,
owner => weird;
"/tmp/bar":
content => 'bar',
mode => 0321,
owner => weird;
}
equivalent Schmitt-style shortcutting:
file {
# defaults block (no title!)
mode => 0321,
owner => weird;
# actual resources block (no mode, owner)
"/tmp/foo": content => 'foo';
"/tmp/bar": content => 'bar';
}
simply allowing the keyword default describe the default would do it. i.e.
file {
default:
mode => '0321',
owner => weird;
'tmp/foo':
content => foo;
'tmp/bar':
content => bar;
}
And, if you wanted a resource with the actual title 'default', you would
quote it.
(We cannot accept a resource without a title due to how the grammar
works - long story)
I can also imagine the capability to reference default values via name -
set elsewhere. It would then be totally up to the designer to configure
them and use them, and all references would be clear.
Being able to set them from a hash is also a lot more powerful since the
content of the hash can be computed much more easily than
the resource default expressions where you basically have to do any
computations first and store in a hash or variable, and then construct
the defaults expression (or some variant with embedded complex logic
inside of the defaults expression which is even messier).
So, I can imagine syntax like below to reference a set of default values:
e.g.
$file_defaults = { mode => '0321', owner => weird }
file {
default: $file_defaults;
'tmp/foo':
content => foo;
'tmp/bar':
content => bar;
}
I can only remember *seeing* Defaults in modules when they leaked to
somewhere I didn't want them to. That's probably the root cause for my
idea of really restricting where the default values can go.
I like the idea of exactly, and explicitly defining what the defaults
are - no surprises. And, it is up to the designer of a module to expose
any wanted variability which is now precise. You can have multiple
(conflicting) sets of defaults that apply to different groups of
resources in the same context etc. (this is impossible today).
If we do this, then we can drop the current resource defaults expression
completely!
Schmitt-style ftw !!
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/lp5163%2472b%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
