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 }
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.
Cheers,
Felix
--
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/545B5DCE.5000205%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.