How about just create a utility define to go with your custom type? E.g. create an rs_tag::conditional define, then use that instead of the rs_tag type directly. You can put the conditional logic in the define and it's about as clean as it gets. You also don't have to muck about with the logic at the provider level.
--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-dev/GWFjYkHT-e8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/de388f38-9daf-4725-aea7-b06b315b30d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
In the type for it to make sense and be consistent with the usual semantics I think you'd have to make it some kind of valid ensurable state. For example, let people specify ensure=present_if_in_rightscale or some better state name.
That also suggests to options like ensure=$is_rightscale or other fact-based approaches, where the fact is either true or undef. That would probably work.
It doesn't make a lot of sense to me to build a type that doesn't fail if I say ensure=present and it can't be present, regardless of why not. Hence why I'd say approach it from the perspective of what you're trying to ensure.
A noop provider could exist that would fail on ensure=present but succeed on ensure=something_else_or_maybe_undef.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAOHkZxMoNN6s-m0y4jgrZe9OgVP6%2BN%3DV4uQvwFA7DrObMfqD-w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAHNFGkPCZHtfRoBB8rSt6ugj13yzkj7JQAbAqT0HQaK1SeJj-w%40mail.gmail.com.