On Mon, Aug 11, 2014 at 8:54 PM, Spencer Krum <krum.spen...@gmail.com>
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.
>
>
I hadn't looked for this information before because I just assumed that if
it is possible it is being used :) However, I just did a quick trawl
through the forge and the following modules use variables for the type in
create_resources:
* vstone-apache
* puppetlabs-swift
* jaydub-resource_factory
* eNovance-cloud
There is also jakeb-system and erwbgy-system which seem to be copies of one
another. They don't use create_resources, but seem to have forked it into a
new function called system_create_resources which is then used with a
variable type. It isn't clear to me what is different about the forked
function.
Looking at the examples, usage of interpolating the type name is usually
done in order to have different defined types for different situations, but
shield the user of the module from needing to know about them. This seems
like a very reasonable use.
> 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
> <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.
>
--
Andrew Parker
a...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer
*Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September
22-24 in San Francisco*
*Register by May 30th to take advantage of the Early Adopter discount
<http://links.puppetlabs.com/puppetconf-early-adopter> **—**save $349!*
--
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/CANhgQXuaED6prcXfcKZTwN%3DWAtFxjEgYPgn5Y4crSKWDqAVDhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
