On 2014-12-08 2:41, Andy Parker wrote:
On Tue, Aug 5, 2014 at 11:25 PM, David Schmitt <da...@dasz.at
<mailto:da...@dasz.at>> wrote:
Hi,
thanks for keeping the ball rolling!
On 2014-08-06 02:51, Andy Parker wrote:
I'm pulling this discussion out into a new thread so that we can
become
more focussed. I'm also going to start a thread about one other
topic
that has been brought to my attention so that a decision can be
reached.
In this thread I'd like to get to a decision about two aspects of
resource expressions:
1. Whether to allow expressions in the type position ($a {
hi: })
> The use case for number 1 is to provide determining the exact
type of a
> resource at runtime. An example would be a module that had different
> implementations for debian vs redhat. It can then use parts of
its self
> like so:
>
> apache::install::$osfamily { 'something': }
>
> Note: I'm not promoting this or saying that this kind of construction
> should appear everywhere, but it is a feature that isn't available in
> the language at the moment.
>
What Trevor said: highly prone to misuse, but for the use case
given, +1 as a shortcut to create_resources.
Note: we talked about $ a having various types, but I think this
question only is about values that are Strings or Types, which I
think is a very sensible restriction to avoid the complexities and
abuses beyond the specified use case.
2. Whether to allow using hashes as resources parameters
3. If we allow hashes as resource parameters, what token
introduces
it (no introducing token isn't an option because of implementation
constraints).
I really like Reid's suggestion to use a proper attribute name
instead of an asterisk.
The use case for number 2 is determining dynamically what parameters
need to be included. In fact I saw a question just recently where
someone tried to do (something like):
service { 'apache':
if $control_service {
ensure => running
}
enabled => true
}
That could be done instead as:
$params = if $control_service {
{ ensure => running }
} else {
{ }
}
service { 'apache':
* => $params;
default:
enabled => true
}
This code gives me the hives. As I've replied in that thread, my
usual way to write this is
service { 'apache':
enabled => true
}
if $control_service {
Service['apache'] { ensure => running }
}
If I were forced to use hashes, I think I'd write something along
these lines:
$service_params = {
enabled => true
}
if $control_service {
$service_params['ensure'] = 'running'
}
create_resource('service', $service_params)
Re-reading that, it could be even argued, that it flows better
because the create_resource is at the end, and all relevant values
are collected before, while my way adds values after the resource
definition. Also the hash version doesn't duplicate the resource
title. I'm beginning to like it even better.
To show Reid's proposal:
$service_params = $control_service ? {
true => { $ensure => 'running' }
false => {}
}
service { 'apache':
enable => true,
defaults => $service_params;
}
also very concise and readable to me.
A second use case is to provide a way of allowing local defaults
to be
reused across multiple resources. And a third one was presented
by Erik.
Are these use cases invalid or not needed? If not, how should
they be
solved? There is create_resources. Is that really a good
solution? I ask
that in all seriousness given that the only purpose of the puppet
language is to construct catalogs of resources to manage
configurations
and the current syntax for those fundamental elements are so
inflexible
that we had to add a function to leave the language for slightly
more
advanced resource creation scenarios.
Puppet Labs has a UX department that is at the ready to perform
any user
testing or usability analysis that anyone thinks might be
valuable to
answer these questions. If we can work out what kinds of
questions there
are we can definitely get some study done.
I do like both the defaults: title keyword and Reid's
'(attribute|param)_(override|__defaults|hash)' metaparam instead of
the splat operator proposals. Both are shorthands for hash
manipulation and a create_resource call. In the most general sense,
the whole Puppet DSL is a shorthand for hash manipulation and
create_resource calls. So for me the questions is, are those
shorthands understandable and valuable, that is, more
readable/modifyable/writeable than a hash+create_resource. Like
Trevor has suggested, we all might not be the best suited to reason
about this ;-)
I just did a quick search through the modules on the forge and the
follow modules all use a parameter called 'attributes':
* sensu-sensu-1.0.0
* deric-mesos-0.2.0 through 0.4.1
* CERNOps-activemq-0.0.1
This is the problem with trying to take a word (and the same problem
that the meta parameters encounter), once that name is taken globally,
then nobody else can use it, no matter how good their intentions :/
In different news, but related, Henrik has started working with the UX
team to come up with something that we can put in front of people to get
a more definitive answer. However, they are saying that they won't be
able to get any results until the end of August. We need to come up with
an interim solution and then probably make some changes in a "bugfix"
release.
And we added yet another option, a compromise of using an operator and a
name.
file { 'title': @attributes => $hash }
The @ only combines with the exact word attributes. This makes it
"googlable", descriptive, does not require name to be reserved, and it
meets the technical requirements (it can be parsed etc).
- 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/lsbsbb%24ek1%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
