On 2014-07-11 18:28, Erik Dalén wrote:
On Fri Nov 07 2014 at 5:29:15 PM John Bollinger
<john.bollin...@stjude.org <mailto:john.bollin...@stjude.org>> wrote:
Having said all that, I can completely get behind Luke's idea to
provide for client-side queries. I am confused, however, as to why
the ideas for that seem to be running in directions such as
overloading resource titles and introducing new collector-like
forms, when the entire purpose of the Resources type is to serve
this kind of function. Why not just add a parameter to Resources to
specify the a query predicate (the default being something like
"!managed", and another to specify a hash of resource properties to
set, e.g. { ensure => absent }. Deprecate the existing 'purge' and
'unless_system_user' parameters. This would look similar to some of
the forms being proposed, but it would rely mostly on existing
facilities for everything other than actually performing queries.
Example:
resources {'remove-unmanaged-users':
name =>'user',
match =>"uid > 100 && !managed",
set=>{ensure=>'absent'}
}
I admit that I'm a bit leery of the "!managed" bit of the predicate,
as its presence suggests that maybe it can be omitted to allow
whatever is implemented for this to modify the properties of
/managed/ resources, too. This could be especially nasty if it were
possible to stack these things so that more than one applies to the
same resource. *I urge that that possibility be foreclosed*, at
least in the initial implementation. It can be added later if there
turns out to be sufficient justification, but it cannot easily be
taken away once granted.
I think this is sensible, likely the parser for this query should be
implemented in the munging method of the type though, so it can happen
server side and turn it into some sort of AST like format (which is what
I meant with something looking a bit like the PuppetDB query API).
Possibly it should allow users to submit that AST format directly, so
then you could have other parser functions to implement different
syntaxes for the query language.
as an example:
instead of match => "title='foo' and version='2.1.2'"
allow something like ["and", ["=", "title", "foo"], ["=", "version",
"2.1.2"]]
And then you could have a function that could return something like that
instead of having to turn it into a string that then gets parsed again.
That is what a query would produce as serialization if allowed as a
value expression. e.g.
match => <| title == foo and version = '2.1.2' |>
the big benefit is that the parser can validate the query, all querying
is expressed the same way, etc. Just as if this was done with a string,
any interpolation is done server side.
match => <| title == foo and version = $ver |>
i.e. $ver is evaluated and the result is stored in the resulting "baked"
query that is sent to the agent.
As part of getting rid of the old 3x AST, we just finished the rewrite
of the Collector. It is now much easier to do the collector expression
encoding transformation to "array form" or "ruby proc predicate" (used
internally for catalog collection and exported collection), and we can
now easily add an "array form" to "ruby proc predicate" transformation
that makes it really easy to use as a filter in a type.
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/m3jrev%24mfb%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
