On Tuesday, July 29, 2014 1:23:09 PM UTC-5, Andy Parker wrote: > > On Thu, Jul 24, 2014 at 5:32 PM, Andy Parker <an...@puppetlabs.com > <javascript:>> 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. >> >> 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. >> >> > Replying to myself...tsk tsk. Oh well. > > This is to provide an update on what's going on. Henrik put together a > bunch of changes to the implementation to carry out these decisions. I > worked on the specification to get it to align with these decisions > > The change to the specification happened in this PR > https://github.com/puppetlabs/puppet-specifications/pull/14 > We've already identified one problem in the specification, it doesn't > allow nested arrays of strings in the title. I have a note to fix that. >
Is support for nested string arrays an intentional current feature? I hadn't thought so, but maybe you slipped in automatic flattening of array titles sometime when I wasn't looking. If it's not a current feature, then does it need to be a future feature? > > The implementation changes are currently in this PR > https://github.com/puppetlabs/puppet/pull/2914 > I'm working through adding tests based on the specification and to explore > what kinds of changes to the current semantics we have got. > > Joshua and I have been working on putting together some tests to not only > test the implementation against the specification, but also to see how > different it really ends up being from the old implementation. The tests > check several different scenarios, but basically, the first item is used as > the title of a resource, the second is whether we expect to create a > resource or get an error. The third element is either the regexp for the > error message or the titles of the resources that actually get created. > > This is for the current system: > > ["thing" ,"resource", ["thing"]], > ["[thing]" ,"resource", ["thing"]], > ["[[nested, array]]" ,"resource", ["nested", "array"]], > And that last one actually works? I would have expected this: ["[[nested, array]]" ,"resource", ["nestedarray"]] , which I don't categorize as "working". > > ["1" ,"resource", ["1"]], # deprecate? > ["3.0" ,"resource", ["3.0"]], # deprecate? > ["[1]" ,"resource", ["1"]], # deprecate? > ["[3.0]" ,"resource", ["3.0"]], # deprecate? > > #["true" ,"resource", ["true"]], literal true doesn't > parse. true as a variable parses and creates a resource > #["false" ,"resource", ["false"]], similar problems to > [false] below. literal false doesn't parse > ["[true]" ,"resource", ["true"]], # this makes no sense > given the next case > ["[false]" ,"error", /No title provided and :notify is > not a valid resource reference/], # *sigh* > > #["undef" ,"resource", ["undef"]], # works for variable > value, not for literal. deprecate? > ["[undef]" ,"resource", ["undef"]], # deprecate? > > I'd say of the above that any value that works as a title when specified indirectly via a variable should also work when specified as a literal, and vise versa. I would be ok with requiring actual strings instead of stringifying values of other types. I believe Henrik promoted that approach. > #["{nested => hash}" ,"resource", ["{nested => hash}"]], doesn't > work for a literal hash (syntax error). In a variable it is created, but > isn't possible to reference the resource. deprecate? > #["[{nested => hash}]" ,"resource", ["{nested => hash}"]], works as > both literal and variable, but isn't possible to reference the resource. > deprecate? > You can't reference the literal because the resource name is not the hash, it is the stringification of the hash. IIRC works out to "nestedhash" in this case. I would be all for deprecating that behavior. As far as I know, it is never used except by mistake, and the errors resulting from that mistake are confusing to the casual Puppet user. > > ["/regexp/" ,"error", /Syntax error/], > ["[/regexp/]" ,"error", /Syntax error/], > > ["default" ,"error", /Syntax error/], > ["[default]" ,"error", /Syntax error/], > > The current system has a lot of odd outcomes in it. > I'd agree with that, but odd as they are, they are also relatively consistent if you look at it from the right perspective. Mostly the behavior springs from the fact that Puppet expects resource titles to be strings, and from the fact that the grammar recognizes and distinguishes the data types of many productions. There's a bit of a tension there, though, because if you sneak a non-string individual resource title to the back end by, say, hiding it in a variable, then the back end just stringifies it instead of rejecting it. > Here are the tests for the future parser (as changed by the PR) > > ["thing" ,"resource", ["thing"]], > ["[thing]" ,"resource", ["thing"]], > ["[[nested, array]]" ,"resource", ["nested", "array"]], > I still find that last one surprising, but if it really matches the current behavior then so be it. What's the rule here, though? Array titles are automatically flattened? > > ["1" ,"error", /Illegal title type.*Expected > String, got Integer/], > ["3.0" ,"error", /Illegal title type.*Expected > String, got Float/], > ["[1]" ,"error", /Illegal title type.*Expected > String, got Integer/], > ["[3.0]" ,"error", /Illegal title type.*Expected > String, got Float/], > > ["true" ,"error", /Illegal title type.*Expected > String, got Boolean/], > ["false" ,"error", /Illegal title type.*Expected > String, got Boolean/], > ["[true]" ,"error", /Illegal title type.*Expected > String, got Boolean/], > ["[false]" ,"error", /Illegal title type.*Expected > String, got Boolean/], > > ["undef" ,"error", /Missing title.*undef/], > ["[undef]" ,"error", /Missing title.*undef/], > > ["{nested => hash}" ,"error", /Illegal title type.*Expected > String, got Hash/], > ["[{nested => hash}]" ,"error", /Illegal title type.*Expected > String, got Hash/], > > ["/regexp/" ,"error", /Illegal title type.*Expected > String, got Regexp/], > ["[/regexp/]" ,"error", /Illegal title type.*Expected > String, got Regexp/], > > ["default" ,"resource", []], # nothing created because > this is just a local default > ["[default]" ,"resource", []], > > I'm a little worried that these changes might be too extreme. Thoughts? > > Beyond what I've already said, I don't personally have a problem with any of the changes highlighted here. 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/76d12bc2-5917-42b9-b397-c5773df8b9fe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
