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 puppet-dev+unsubscr...@googlegroups.com. 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.