So for now our status means trying to do this in the language without
an actual change to Puppet is becoming hard. This is entirely
possible, but we'll have to ship with environment support without
constraint capability today most probably.
The only other 'quick and dirty' option I can think of is to do this
back in the terminus configuration again, which some people are
clearly not fans of.
Any other ideas from those watching at home?
ken.
On Fri, Apr 11, 2014 at 12:44 AM, Ken Barber <k...@puppetlabs.com> wrote:
>> 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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAE4bNT%3DSNGgTQTQxHQGGmZp-t4VBY7tM7fd9SyM_QH91K9K4NA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
