Okay. Thanks.
On Fri, Jul 25, 2014 at 5:39 AM, Henrik Lindberg <
henrik.lindb...@cloudsmith.com> wrote:
> On 2014-25-07 3:32, Spencer Krum wrote:
>
>> I'm not sure if this is the correct time to mention this, but I wonder
>> if you considered arrays of hashes in decision eight?
>>
>> I guess they are not really arrays of hashes but whatever this is:
>>
>> [
>>
>> '/root/file1' => {'owner' => 'root'},
>> '/root/file1' => {'owner' => 'nibz'},
>> ]
>>
>> Right now we often use arrays of hashes with the create_resources
>> function when we need to specify parameters. This is similar to the
>> effect of how arrays passed into resources as title behave.
>>
>> I think it would be awesome if we could pass what we currently pass into
>> create_resources into resource instantiations.
>>
>>
> You mean like this?
>
> $x = [
>
> '/root/file1' => {'owner' => 'root'},
> '/root/file1' => {'owner' => 'nibz'},
> ]
> file { $x: }
>
> When we discuss this, we preferred that the iteration is made explicit.
> You can use the same data structure, and do this:
>
> $x.each |$title, $attributes| { file { $title: * => $attributes } }
>
> Since that is much more descriptive. (In fact, that is pretty much what
> the implementation of create resources is).
>
> - henrik
>
> Thanks,
>> Spencer
>>
>>
>> On Thu, Jul 24, 2014 at 6:04 PM, Henrik Lindberg
>> <henrik.lindb...@cloudsmith.com <mailto:henrik.lindb...@cloudsmith.com>>
>>
>> wrote:
>>
>> On 2014-25-07 2:32, Andy Parker wrote:
>>
>> DECISION TWO
>>
>> Resource instantiations are value producing expressions
>>
>> The expression based grammar that puppet 4 will be based on
>> changed
>> almost everything into a general expression, which allowed a lot
>> of
>> composition that wasn't possible before. This didn't change
>> resource
>> expressions. Resource expressions could not be assigned ($a =
>> notify
>> {hi:}). That is being changed. This removes several odd corners
>> in the
>> grammar and makes it all more consistent. It is also highly
>> unlikely
>> that it would be removed later (principle 1). The value of a
>> resource
>> expression is a reference to the created resource, or an array of
>> references if there is more than one.
>>
>> QUESTION: should the value always be an array of references?
>> That would
>> make it much more predictable.
>>
>> DECISION THREE
>>
>> Resource instantiation expressions will not be allowed in
>> dangerous
>> locations
>>
>> Once resource expressions can be placed anywhere there are a few
>> places
>> where they would actually just do more harm than good (principle
>> 2). One
>> example is as a parameter default (define a($b = notify {hi:})
>> {}).
>>
>> DECISION FOUR
>>
>> The LHS of a resource *instantiation* expression can be an
>> expression
>>
>> What?!? This means you can do:
>>
>> $a = notify
>> $a { hi: }
>>
>> Once again, in clearing up odd cases in the grammar this is
>> opened up to
>> us. This is a very powerful feature to have available. Since this
>> is
>> very useful and fits well into the grammar I don't see this being
>> a
>> temporary thing that would then have to go away later (principle
>> 1).
>>
>> DECISION FIVE (how many of these are there?)
>>
>> A resource with a title of default provides the default
>> parameter
>> values for other resources in the same instantiation expression.
>>
>> Thanks to David Schmitt for this idea!
>>
>> Since we aren't going to change the behavior of resource default
>> expressions (Notify { ... }) it seems like there needs to be
>> something
>> done to provide a better, safer way of specifying defaults. This
>> will allow:
>>
>> notify {
>> default: message => hi;
>> bye: }
>>
>> The result will be a resource of type Notify with title bye and
>> message
>> hi. It is highly unlikely that this will go away (principle 1)
>> as it is
>> syntactic sugar for specifying the parameters for every resource.
>>
>> DECISION SIX
>>
>> There will be a splat operator for resource instantiation
>> expressions
>>
>> To make the default resources (decision five) really useful
>> there needs
>> to be a way to reuse the same values across multiple defaults. The
>> current, dangerous, semantics of resource default expressions
>> skirt this
>> issue by making defaults part of the (dynamic) evaluation scope.
>> In
>> order to make the default resources nearly as useful but much
>> safer, we
>> need to add a way to allow reuse of defaults across multiple
>> resource
>> instantiation expressions explicitly (principle 2).
>>
>> $owner_mode = { owner => andy, mode => '777' } # gotta make
>> it secure
>> file { default: *=> $owner_mode;
>> '/home/andy/.bashrc': ;
>> '/home/andy/.ssh/id_rsa': ;
>> }
>>
>> file { '/etc/passwd': *=> $owner_mode }
>>
>> As a side note, do you see what can now be done?
>>
>> $a = notify
>> $b = hi
>> $c = { message => bye }
>> $a { $b: *=> $c }
>>
>> DECISION SEVEN
>>
>> undef is not allowed as a title
>>
>> Not much to say here. notify { undef: } fails (or anything that
>> evaluates to undef)
>>
>>
>> DECISION SEVEN AND 3/4
>>
>> A title expression must result in a String value, or Array of String
>> values.. No regular expressions, hashes, booleans, numbers etc.
>>
>>
>> No magic turning a title into a string if it is not.
>>
>> DECISION EIGHT
>>
>> An array as a title expands to individual resource
>> instantiation
>> expressions with titles of the elements of the array.
>>
>> This isn't really too far off from the current semantics, no
>> real change
>> here. It is only to call out that we are formalizing that as the
>> semantics. An empty array ends up being a noop (no resources
>> instantiated). An array that contains undef will produce an
>> error (see
>> decision seven). The value default can be an element of the
>> array and
>> will produce the default section for the resources being
>> instantiated
>> (as pointless as that seems since they will all have the same
>> body).
>>
>> DECISION NINE
>>
>> Decisions two through eight do not apply to resource default or
>> resource override expressions.
>>
>> Just to make it clear that decision one still holds.
>>
>> CONCLUSION
>>
>> I think that covers it all. This will be reflected by a revert
>> to some
>> code, modifying the grammar, adding some new evaluation
>> capabilities,
>> including tests, and updating the specification. All of this is
>> falling
>> under PUP-501, PUP-511, and PUP-2898 in some way shape or form.
>>
>> This email was to record the decisions; make them public; double
>> check
>> that Henrik, Joshua and I all had the same understanding of
>> them; and
>> give another chance to everyone to weigh in.
>>
>> I did have one question that I uncovered as I was writing this
>> up. Some
>> feedback on that would be great as well.
>>
>> --
>> Andrew Parker
>> a...@puppetlabs.com <mailto:a...@puppetlabs.com>
>> <mailto: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
>>
>> <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+unsubscribe@__googlegroups.com
>> <mailto:puppet-dev%2bunsubscr...@googlegroups.com>
>> <mailto:puppet-dev+__unsubscr...@googlegroups.com
>> <mailto:puppet-dev%2bunsubscr...@googlegroups.com>>.
>>
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/__msgid/puppet-dev/__
>> CANhgQXu3HVrWJrTnMgYvbY6%__3DR8B%__3DvVgts2Uqmwjtj6eJRJsH7g%__
>> 40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-dev/
>> CANhgQXu3HVrWJrTnMgYvbY6%3DR8B%3DvVgts2Uqmwjtj6eJRJsH7g%40mail.gmail.com>
>> <https://groups.google.com/d/__msgid/puppet-dev/__
>> CANhgQXu3HVrWJrTnMgYvbY6%__3DR8B%__3DvVgts2Uqmwjtj6eJRJsH7g%__
>> 40mail.gmail.com?utm_medium=__email&utm_source=footer
>> <https://groups.google.com/d/msgid/puppet-dev/
>> CANhgQXu3HVrWJrTnMgYvbY6%3DR8B%3DvVgts2Uqmwjtj6eJRJsH7g%
>> 40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>>
>> For more options, visit https://groups.google.com/d/__optout
>> <https://groups.google.com/d/optout>.
>>
>>
>>
>>
>> --
>>
>> 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/lqsaff%2438h%
>> __241%40ger.gmane.org
>> <https://groups.google.com/d/msgid/puppet-dev/lqsaff%2438h%
>> 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/CADt6FWNcOa2vaxx_vNn%
>> 2BNTX1tmngeF2KEi0mspQcCxUBrh3mYg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-dev/CADt6FWNcOa2vaxx_vNn%
>> 2BNTX1tmngeF2KEi0mspQcCxUBrh3mYg%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/lqtj6g%24png%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/CADt6FWMVO-yk5WDQvR%3Dq3gMDHo1hCy6XGWKvJqBDn5ctXQOdkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
