On Sun, Aug 3, 2014 at 1:22 PM, Luke Kanies <l...@puppetlabs.com> wrote:
> On Jul 28, 2014, at 7:33 AM, Henrik Lindberg < > henrik.lindb...@cloudsmith.com> wrote: > > > On 2014-28-07 8:34, Luke Kanies wrote: > >> On Jul 24, 2014, at 5:32 PM, Andy Parker <a...@puppetlabs.com > >> <mailto:a...@puppetlabs.com>> wrote: > >> > >>> Howdy, > >>> > >>> Henrik, David, Erik, John, and others have been having some pretty > >>> epic conversations around resource expressions, precedence, order of > >>> evaluation, and several other topics. What kicked all of that off was > >>> us looking for some feedback on decisions we were making for the > >>> Puppet 4 language about how resource overrides, defaults, and so on > >>> actually work (or don't in some cases). I think we've finally reached > >>> some decisions! > >>> > >>> Henrik took all of the ideas and started trying to work out what we > >>> could do and what we couldn't. Those are in a writeup at > >>> > https://docs.google.com/a/puppetlabs.com/document/d/1mlwyaEeZqCfbF2oI1F-95cochxfe9gubjfc_BXjkOjA/edit# > >> > >> > >> Sorry for the late comments here, but I have a couple of questions and > >> comments. > >> > >>> Lots of information in there, so here is the summary. > >>> > >>> The principles behind the decisions: > >>> 1. Only make changes that have a high likelihood of *not* needing to > >>> be backed out later. > >>> 2. Strict or explicit is better than lax or implicit. It uncovers > >>> issues and keeps you from lying to yourself. > >>> 3. Puppet 3 has already stacked up a lot of changes. Do not break > >>> manifests unless we really have to. > >>> 4. Let's not break manifests and then have to break them in almost > >>> the same way once we start working on a new catalog system. > >> > >> Great principles. It would be good to see these paired with what fits > >> into the "we really have to" section of #3. > >> > > Mostly, the "we have to" issues are those that relates to strictness, > where it previously was relaxed and/or had undefined behavior. > > Ok. Again, it would be good to see those documented. > > Many of the cases where things have changed are documented at http://docs.puppetlabs.com/puppet/3.6/reference/experiments_future.html As Henrik said in an earlier reply the "we have to" changes mostly came from working to make things behave in the way people have expressed that they expect it to behave. Sometimes these were changes to interpretation of some element of the language, such as undef, which has fairly localized effects. Others have had impacts on the entire grammar (such as allowing literals in certain places). > [...] > >> > >>> 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 } > >> > >> As above, this makes the language much more powerful and complex, and it > >> seems like makes it possible to build truly unreadable code without > >> trying very hard. > >> > >> What's the use case for this, and why is that use case important enough > >> to justify this increase in complexity? > >> > > > > This is to support what is otherwise done in an opaque fashion with Ruby > templates, or calling the create_resources function. It is mostly done by > module authors that integrate with other modules, and where it is not known > at authoring time what the name of the type is. > > > > It allows allows a transformation of data to resources to be expressed > in the puppet language. Again, the alternative is to transform to a generic > hash and then call create_resources. Sometimes people create their own > variants of create_resources as custom function because it > > has been difficult to perform such transformations in the puppet > language. > > > > We believe that the ability to have indirection for the type is a better > solution than the alternatives, even if looks more complex, it makes the > logic visible and reduces the dependency on Ruby. > > I am not convinced. Based on what I've seen so far, I prefer > transformation to a hash, and using a function. This is a lot of > syntactical power, and it is being done to replace what seems like > relatively simple hash operations and a simple function. > > Another case that we had in mind when putting this together was how to handle defaults. Since we are not changing the resource default expression, there is a problem where you want defaults local to a scope (class or define), but don't want to screw up other things in the dynamic scope by using the resource defaults expression. The *=> allows manifest authors to handle this case without large amounts of duplication: $file_defaults = { owner => puppet, group => puppet } ... file { default: *=> $file_defaults; ... } ... file { default: *=> $file_defaults; ... } > I know this wouldn't cover every case, but wouldn't it cover the majority > of cases, and thus be a better trade-off? That is, we have a somewhat less > powerful language, but a much more accessible language, and it comfortably > covers the 95%+ use cases while still being usable by 95%+ of its users? > > -- > http://puppetlabs.com/ | http://about.me/lak | @puppetmasterd > > -- > 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/7BA49B49-5B61-4C2A-8EA4-C431B92811AF%40puppetlabs.com > . > 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/CANhgQXvYYY8_S4c8GM02zPAL6%2BKEW2F3r2%3DYX_bmqDZJZkQpaw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
