Okay. Thanks.
On Fri, Jul 25, 2014 at 5:39 AM, Henrik Lindberg < [email protected]> 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 >> <[email protected] <mailto:[email protected]>> >> >> 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 >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> >> >> 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%[email protected]> >> <mailto:[email protected] >> <mailto:puppet-dev%[email protected]>>. >> >> >> 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%[email protected]>. >> >> 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 [email protected] >> <mailto:[email protected]>. >> 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 [email protected]. > 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 [email protected]. 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.
