On 2014-12-08 5:54, Spencer Krum wrote:
1) I really don't want to see variable expansion in expressions that
resolve to the names of types. This will be misused, it will make code
unreadable. Please leave it out. Sets of parameters only make sense to
distinct types anyways, if two types really do accept all the same
parameters, then the RAL should be leveraged and different providers
written.
It is already used (via create_resources), and people want it to support
integration use cases between more tightly coupled modules.
2) I think allowing a params_hash metaparmeter to be expanded out into
the parameters that the type takes is a great idea. The behavior I would
expect is that any specifically called out parameter would override the
value found in the hash. It was pointed out before that this presents a
problem for undef, I don't have a solution for that. I would like to be
able to specify undef and still have that override what is found in the
params_hash.
3) I absolutely think a word/metaparameter must be used. I don't really
care what it is but it should be unique and googleable. I don't like
'attributes' because its not unique enough to search on.
What do you think about the proposal to precede the "meta parameter"
name with @, since we have issues with reserving yet another name (all
good names seems to be in use somewhere already).
We proposed @attributes, so by analogy, it would be @params_hash, or
equivalent using the word you preferred.
I think the addition of the params_hash metaparameter makes the
'default:' directive unnecessary.
$files = [
'/root/file1' => {'owner' => 'root', 'mode' => '0700'},
'/root/file1' => {'owner' => 'nibz'},
]
$defaults = {
'mode' => '0644',
}
$files.each | $title, $attributes |
$params = merge($files, $defaults)
file { $title:
params_hash => $params,
}
}
I understand the idea (although the code seems a bit wrong as it will
end up attempting to create a file resource with the title mode, and a
$params with the value of '0644' (and then fail because it is not a hash).
(you probably wanted $params = $defaults + $attributes)
I think this is better because now all the logic of create_resources is
present here in the puppet code: the merging of defaults with specified
parameters AND the iteration.
Yes, that is basicially rolling your own create_resources in a way that
it a bit more understandable. (I like that approach). And yes, when you
do it this way, you can control all aspects of what is default, and what
overrides by just changing the way hashes are merged.
Regards
- henrik
Thanks,
Spencer
On Mon, Aug 11, 2014 at 6:58 PM, Henrik Lindberg
<henrik.lindb...@cloudsmith.com <mailto:henrik.lindb...@cloudsmith.com>>
wrote:
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>
<mailto: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/
<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+unsubscribe@__googlegroups.com
<mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/__msgid/puppet-dev/lsbsbb%24ek1%__241%40ger.gmane.org
<https://groups.google.com/d/msgid/puppet-dev/lsbsbb%24ek1%241%40ger.gmane.org>.
For more options, visit https://groups.google.com/d/__optout
<https://groups.google.com/d/optout>.
--
Spencer Krum
(619)-980-7820
--
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
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CADt6FWOZ6rPngVxbjD5NxxSLNR9Q2N2m6KEog_9TBcMfDQXFhQ%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CADt6FWOZ6rPngVxbjD5NxxSLNR9Q2N2m6KEog_9TBcMfDQXFhQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
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/lsddd8%248c6%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
