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.
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.
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 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.
Thanks,
Spencer
On Mon, Aug 11, 2014 at 6:58 PM, Henrik Lindberg <
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>> 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.
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CADt6FWOZ6rPngVxbjD5NxxSLNR9Q2N2m6KEog_9TBcMfDQXFhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
