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.

Reply via email to