On Nov 6, 2014, at 10:38 PM, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
> On 11/06/2014 12:04 PM, Luke Kanies wrote:
>> A fourth option would be to combine the best of Resources and exported
>> resources: Build a querying system akin to exported resources, but
>> against the current system, rather than against the catalog. Or really,
>> take the exact same querying we already have, but provide the ability to
>> control where it's searching against, and what to do with the results.
>>
>> This is my preferred solution. It makes querying more powerful, and
>> separates the concept of querying from the source of the data.
>
> This is a very attractive idea.
>
> Currently the purging through resources is likely to appear entirely too
> mystical to most users.
>
> To get a behavior that matches today's resources type, we'd need to
> explicitly query unmanaged resources.
>
> User<~| managed == false |~> { ensure => absent }
>
> This has the advantage of being more explicit about the unmanaged part than
>
> resources { 'user': purge => true }
Agreed.
We do need some way to make it clear that this query happens on the client,
rather than on the server, and then the catalog needs some way to store that
query.
The only other way to do it would be to have the server be able to do real-time
queries against the client, but I think that would have too many crazy
consequences.
It’s been a long time, but I seem to remember trying to treat the resource as a
query; something like:
user { *:
uid >= 100,
purge => true
}
But I think this is not the right answer.
Maybe something like:
user { <| uid > 100 |>:
purge => true
}
Then the title is the query, and the parameters get applied to all resources
that match that title.
Thoughts?
> With that said, if we end up staying on the resources type track, I'd
> lean towards Raphael's suggestion from his reply: Add providers to for
> the resources type. Take the magic from the type, add a slew of
> providers. This would move this problem into the space of, say, things
> like package installation options, for which there are patterns in place.
>
> I think I would prefer that over making resources a core concept.
--
http://puppetlabs.com/ | http://about.me/lak | @puppetmasterd
--
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/1C72B882-1E47-4BF8-B7CA-9173353BEBAB%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.
