Making a Puppet custom Type 'optional'...

[Matt Wise]

We have a custom type provider (rs_tag) that I would like to make 'optional' ... that is, if you define a resource rs_tag{'foo': value => 'bar'} and the rs_tag provider cannot be loaded up, that Puppet just moves on and basically fails gracefully. One method I thought might work was to have a second 'provider' thats a 'noop' provider basically ... but I thought that might be hokey.

Is there a cleaner way to do this? Otherwise all of the code that calls 'rs_tag{ ... }' will need to be wrapped in some kind of "if in rightscale..." statement, which feels really super ugly.

[Reid Vandewiele]

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.

[Matt Wise]

Thats definitely one way to do it... and in fact, I may do that today if I can't come up with another solution. I'd prefer to do it in the actual provider, but I could see how this is arguably cleaner. Before I do that though, is there no clean way to do this inside the Type or Provider?

Matt Wise

Sr. Systems Architect

Nextdoor.com

On Fri, May 23, 2014 at 11:12 AM, Reid Vandewiele <re...@puppetlabs.com> wrote:

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.

[Reid Vandewiele]

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.

[Matt Wise]

Reid,

  Ultimately, I went with your original suggestion ... it made more sense to build an 'rs_tag::conditional' definition that does the logic. Its done and implemented, thanks for the idea!

Matt Wise

Sr. Systems Architect

Nextdoor.com

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAHNFGkPCZHtfRoBB8rSt6ugj13yzkj7JQAbAqT0HQaK1SeJj-w%40mail.gmail.com.