On Jul 28, 2014, at 7:33 AM, Henrik Lindberg <[email protected]> wrote:
> On 2014-28-07 8:34, Luke Kanies wrote: >> On Jul 24, 2014, at 5:32 PM, Andy Parker <[email protected] >> <mailto:[email protected]>> 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. [...] >> >>> 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. 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 [email protected]. 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.
