On Tue, Aug 5, 2014 at 11:25 PM, David Schmitt <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.
>
> Regards, David
>
>
> On Tue, Aug 5, 2014 at 4:11 PM, Henrik Lindberg
>> <henrik.lindb...@cloudsmith.com <mailto:henrik.lindb...@cloudsmith.com>>
>>
>> wrote:
>>
>> On 2014-05-08 18:24, Andy Parker wrote:
>>
>> On Tue, Aug 5, 2014 at 8:18 AM, Erik Dalén
>> <erik.gustav.da...@gmail.com <mailto:erik.gustav.da...@gmail.com>
>> <mailto:erik.gustav.dalen@__gmail.com
>>
>> <mailto:erik.gustav.da...@gmail.com>>> wrote:
>>
>> On 5 August 2014 16:25, Reid Vandewiele
>> <r...@puppetlabs.com <mailto:r...@puppetlabs.com>
>> <mailto:r...@puppetlabs.com <mailto:r...@puppetlabs.com>>>
>>
>> wrote:
>>
>> On Mon, Aug 4, 2014 at 3:18 PM, Henrik Lindberg
>> <henrik.lindberg@cloudsmith.__com
>> <mailto:henrik.lindb...@cloudsmith.com>
>> <mailto:henrik.lindberg@__cloudsmith.com
>>
>> <mailto:henrik.lindb...@cloudsmith.com>>> wrote:
>>
>>
>> So, to summarize: The use of * => as an operator is
>> not
>> liked but the concept of being able to set
>> attributes from a
>> hash is. Unfortunately, it is not possible to
>> directly allow
>> an expression at the position in question, there
>> must be a
>> syntactical marker.
>>
>> As pointed out earlier, the * => was thought to read
>> as
>> "any_attribute => from_these_values", but I totally
>> grok if
>> people have an allergic reaction.
>>
>> We can do this though:
>>
>> file { default: ($hash) }
>>
>> This works because it is impossible to have an
>> attribute
>> name in parentheses.
>>
>> In use:
>>
>> file (
>> default : ($my_file_defaults + { mode =>
>> '0666' });
>> '/tmp/foo': ;
>> '/tmp/bar': ;
>> }
>>
>> Is that better? No new operator, but you have to use
>> parentheses around the expression.
>>
>> We can naturally also revert the functionality, but
>> it seems
>> it is liked conceptually.
>>
>>
>> - henrik
>>
>>
>>
>> I think the parenthesis are far preferable over *=>.
>> That isn't
>> to say I like them - I don't particularly. But the
>> functionality
>> is desirable, and if it's a matter of a technical
>> limitation
>> then parenthesis are a Good Enough (TM) compromise from
>> the more
>> ideal direct use of a hash.
>>
>>
>> I really prefer the use of * => over the parenthesis.
>> Especially if
>> you need to merge things into the hash. For example look at
>> this
>> example:
>>
>> # using parenthesis hash style
>> class foo (
>>
>> $servername = $::fqdn,
>> $port = 80,
>> $ssl = false,
>> $extra_opts={},
>>
>> ) {
>> apache::vhost { $servername: ($extra_opts + {
>>
>>
>> port => $port,
>> ssl => $ssl,
>> })
>>
>> }
>> }
>> # using * =>
>> class foo (
>>
>> $servername = $::fqdn,
>> $port = 80,
>> $ssl = false,
>> $extra_opts={},
>>
>> ) {
>> apache::vhost { $servername:
>>
>> port => $port,
>> ssl => $ssl,
>> * => $extra_opts,
>>
>>
>> }
>>
>> }
>>
>>
>> The behavior that we worked out doesn't allow having the splat
>> along
>> with the other parameters, the reason being that it isn't clear
>> what is
>> meant by that. You had in your head that port and ssl are
>> overridden by
>> extra_opts (possibly because they come first?), but another,
>> completely
>> reasonable interpretation is that it is the other way around
>> (port and
>> ssl override extra_opts because they are explicitly given. In
>> order to
>> remove any of that confusion the current specification and
>> implementation doesn't allow mixing. That can, I think, be
>> changed.
>>
>> In the current implementation this would need to be:
>>
>> apache::vhost { $servername:
>> * => $extra_opts + { port => $port, ssl => $ssl }
>> }
>>
>> IMO the *=> is way more readable (as gist here if formatting
>> is
>> screwed up for you:
>> https://gist.github.com/dalen/__57b37b80a9ba1879b78c
>> <https://gist.github.com/dalen/57b37b80a9ba1879b78c>). This is
>> quite
>>
>> similar to what I linked earlier that I am doing in
>> https://github.com/spotify/__puppet-puppetexplorer/blob/__
>> master/manifests/init.pp#L89-__L97
>>
>> <https://github.com/spotify/puppet-puppetexplorer/blob/
>> master/manifests/init.pp#L89-L97>
>> So it is not just a contrived example.
>>
>>
>> My argument against using parenthesis is that parenthesis, are
>> often
>> read as "seldom necessary grouping". I believe that most
>> programmers
>> read them as usually only needed for fixing precedence problems,
>> which
>> is really what is happening here but it doesn't look like it.
>> Based on
>> that I can imagine that a common, and frustrating mistake would
>> be:
>>
>> apache::vhost { $servername: $opts }
>>
>> And then confusion and anger and bug reports.
>>
>>
>> Yeah, I think they are too subtle too (and hence the * =>).
>>
>>
>> One more proposal :-)
>>
>> We could leave out the name part all together (i.e. drop the '*').
>>
>> dalens' example would then look like this:
>>
>>
>> apache::vhost { $servername:
>>
>> port => $port,
>> ssl => $ssl,
>> => $extra_opts,
>>
>> And if it is used for local defaults (or the only thing for a titled
>> resource):
>>
>> file { default: => $hash }
>> file { '/tmp/foo': => $hash }
>>
>> This works best if it is restricted to being the only attribute
>> operation for a title, but looks a bit odd when presented in a list
>> where there are also named (i.e. name => expression) operations.
>>
>> At least it is not a new operator.
>>
>> Is this better than * => or requiring parentheses ?
>>
>>
>> - 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/lrrobu%245b1%
>> __241%40ger.gmane.org
>> <https://groups.google.com/d/msgid/puppet-dev/lrrobu%245b1%
>> 241%40ger.gmane.org>.
>>
>> For more options, visit https://groups.google.com/d/__optout
>> <https://groups.google.com/d/optout>.
>>
>>
>>
>>
>> --
>> Andrew Parker
>> a...@puppetlabs.com <mailto: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
>> <mailto:puppet-dev+unsubscr...@googlegroups.com>.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/
>> CANhgQXvw3AxSQgrUQQKpMyrCNPkdci9gytum-C832C7_q8v6xQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-dev/
>> CANhgQXvw3AxSQgrUQQKpMyrCNPkdci9gytum-C832C7_q8v6xQ%40mail.
>> gmail.com?utm_medium=email&utm_source=footer>.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> * Always looking for people I can help with awesome projects *
> G+: https://plus.google.com/+DavidSchmitt
> Blog: http://club.black.co.at/log/
> LinkedIn: http://at.linkedin.com/in/davidschmitt
>
>
> --
> 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/53E1CA3D.4070509%40dasz.at.
>
> 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/CANhgQXsm%3DdZh9YpsDaT0TYdFbD-8%3DdWpuYsR%3DC3CoD%2BFkbc9og%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
