> The 3x/current parser is very picky what it allows in the query. The only
> chance of doing someting special, is to reserve some particular expressions
> that would otherwise be interpreted as a regular query - i.e. checking
> equality on a virtual parameter name or something like that. This is both
> messy, and error prone, and not probably not
> easier to implement than the alternatives (i.e. change the 3x grammar if
> this is to appear before Puppet 4).
Okay.
> If considering changing the 3x grammar to accept
> Environment[name, Resource] as its LHS seems quite doable, if the rest can
> remain the same. This would be compatible with the future parser language
> wise. (In 4x we just have to do whatever is needed in the transformation to
> the query API).
>
> The other suggestion (a "function call") is probably the same amount of work
> in 3x, and also easy to deal with in 4x.
I wouldn't want to sacrifice a nice grammar for getting anything
rushed in too much. Especially if we see a greater capability down the
road for a more complete query capability.
>> I figure:
>>
>> * We could use something like catalog_environment overriding the
>> ability to collect on a real catalog_environment parameter in the slim
>> chance of a collision.
>> * Fix the language to support something going forward, future parser
>> style.
>>
>> The latter will take some time, and probably involve you directly
>> Henrik for the design.
>>
> I will be glad to help with that.
> With the future parser there is a lot more leeway - this because it is the
> validation steps that forbids constructs that are illegal semantically in
> the Puppet Language, but still parses (following the principle, "I hear what
> you are saying, and you are wrong because", as opposed to going "na na na
> na, can't hear you"... anyway...
So much nicer, doing training I had an eye for picking up bugs in the
code but it was always by feel more than just 'reading the error
message'.
> Internally syntax wise it is something like:
>
> CollectionExpression
> : Expression Query ('{' ... '}')?
> ;
>
> Query
> : '<|' Expression? '|>'
> | '<||' Expression? '||>'
> ;
>
>
> i.e. there is a lot of flexibility when parsing. The query operators have
> higher precedence than most operators, but you can always put an expression
> in parentheses - e.g.
>
> (1+2) <| query |>
>
> Even if that particular example is meaningless, a function call is not (one
> that returns the type to query), or a variable expression - e.g.
>
> $x = Environment[production, File]
> $x <| ... |>
>
> Note that the query is just one Expression, i.e. parser wise it could be:
> a + b * 3 == 4 and foo(1,2,3) + bar or true != false and blah(blah)
>
> The validator kicks in after parsing and raises errors for anything that is
> illegal. The validator has one particular way to treat the expression
> allowed in a query. Thus to experiment, you would need a tweaked validator.
> (Not hard to do when playing with it/ trying things out)
>
> If you want to go out on a limb - calls supports lambdas, and those can be
> transformed to something else (think clojure...) that way you could send a
> function to execute on the server. Validation can ensure that it only
> contains supported expressions....
>
> I think there is a lot that can be done wrt supporting queries expressed in
> the Puppet Language.
So here is the current bit of interesting. When you provide a
constraint in a naive way:
Notify <<| catalog_environment == $::environment |>>
It more or less works to a certain extent, however my first example
failed. And you'll laugh when you hear why.
When you export and collect on the same node, its up to Puppet to do
the collection internally. This is so it can do lazy evaluation
presumably, and its also a chicken and egg problem ... it needs all
the collected resources before it can create a full catalog. So in the
case of a node exporting and collecting its own resources, it doesn't
know about catalog_resources so it just doesn't match.
Now we get the query via the the PuppetDB terminus, but we always
specifically stop the collection for itself:
["and",
["=", "type", "Notify"],
["=", "exported", true],
["not", ["=", "certname", "kb.local"]],
["=", "environment", "production"]]
This is to avoid the duplication problem, not to mention you don't
want to collect the resources from the _last_ catalog, it isn't up to
date.
What this means is, while this solution would work for collection from
other nodes, it fails to work when you are export and collecting on
the same node. So at the moment, even something naive like
catalog_environment == $::environment doesn't work without a Puppet
change most probably.
ken.
--
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/CAE4bNTk5cPM5rOZd1OmUajW2UMVLmDWchSirFdFStBakzWbL9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
