On Thursday, July 24, 2014 7:32:13 PM UTC-5, Andy Parker 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#
>
>
> 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.
> There are three kinds of resource expression that we have to deal with:
>
> 1. Resource instantiation
> 2. Resource defaults
> 3. Resource overrides
>
> Looking forward, I think it is highly likely that the catalog system that
> we'll be working on during puppet 4 will be some sort of production (rules)
> system. In that kind of a world, resource instantiation likely remains as
> is, but defaults and overrides will end up having to change quite a bit, if
> not in syntax, at least in semantics.
>
> DECISION ONE
>
> Resource defaults and Resource overrides will be left untouched.
>
> Decision one follows from principles 3 and 4. In the discussions it became
> clear that changing when defaults or overrides are applied, the scope of
> defaults, or anything else about them was going to cause a lot of problems.
> Puppet's master branch changed resource defaults to follow the same scoping
> rules as variables. That change will be reverted.
>
I take it you mean that the current syntax for overrides and defaults will
continue to be supported and will continue to have the traditional
semantics. Do you also mean that the new form of default declarations will
also have the same semantics (scope, laziness, ...) as the traditional
ones? (I suspect not.)
>
> DECISION TWO
>
> Resource instantiations are value producing expressions
>
>
Love it.
What about collection expressions? Or does their late evaluation present
too much of a problem?
>
>
> QUESTION: should the value always be an array of references? That would
> make it much more predictable.
>
How about making the value an array if and only if the title given in the
resource instantiation expression is an array? In most cases either you
know the type of the title or you don't care; in the odd case that you
don't know the type of the title but you do care about the result being an
array then you can write
$array = flatten( [ notify {$maybe_array: message => 'hi' } ] )
(requires stdlib).
If you want an array but you have only a single title then you can write
either
$array = notify { [ 'adieu' ]: message => 'bye' }
or
$array = [ notify { 'adieu': message => 'bye' } ]
>
> 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:}) {}).
>
Sounds wise, but even after reading the details in your googledoc I'm not
sure I follow the details.
>
> 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).
>
>
This one makes me a bit uncomfortable, but I could see it maybe being
useful. Are there limitations on the value produced by an expression used
as the LHS of a resource instantiation expression? For instance, that it
must evaluate to either a string or a (resource) type?
> 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!
>
>
Yes, this is cool.
> 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 }
>
>
"*=>" looks weird, even for Puppet. What about contracting it to "*>",
parallel to the plussignment operator (+>) and to the ordinary value
binding operator (=>)?
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.
>
Is there any change *at all* there with respect to what current Puppet
already supports? (I don't see any, but you've spooked me.)
John
--
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/a75c8591-24a8-4240-a23c-319491d5dbbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
