[Puppet-dev] Making a Puppet custom Type 'optional'...
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 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/de388f38-9daf-4725-aea7-b06b315b30d2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Making a Puppet custom Type 'optional'...
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 r...@puppetlabs.comwrote: 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+unsubscr...@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. -- 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/CAOHkZxMoNN6s-m0y4jgrZe9OgVP6%2BN%3DV4uQvwFA7DrObMfqD-w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Making a Puppet custom Type 'optional'...
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. On May 23, 2014 11:16 AM, Matt Wise m...@nextdoor.com wrote: 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 r...@puppetlabs.comwrote: 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+unsubscr...@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. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAOHkZxMoNN6s-m0y4jgrZe9OgVP6%2BN%3DV4uQvwFA7DrObMfqD-w%40mail.gmail.comhttps://groups.google.com/d/msgid/puppet-dev/CAOHkZxMoNN6s-m0y4jgrZe9OgVP6%2BN%3DV4uQvwFA7DrObMfqD-w%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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/CAHNFGkPCZHtfRoBB8rSt6ugj13yzkj7JQAbAqT0HQaK1SeJj-w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Making a Puppet custom Type 'optional'...
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 On Fri, May 23, 2014 at 11:31 AM, Reid Vandewiele r...@puppetlabs.comwrote: 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. On May 23, 2014 11:16 AM, Matt Wise m...@nextdoor.com wrote: 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 r...@puppetlabs.comwrote: 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+unsubscr...@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. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAOHkZxMoNN6s-m0y4jgrZe9OgVP6%2BN%3DV4uQvwFA7DrObMfqD-w%40mail.gmail.comhttps://groups.google.com/d/msgid/puppet-dev/CAOHkZxMoNN6s-m0y4jgrZe9OgVP6%2BN%3DV4uQvwFA7DrObMfqD-w%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAHNFGkPCZHtfRoBB8rSt6ugj13yzkj7JQAbAqT0HQaK1SeJj-w%40mail.gmail.comhttps://groups.google.com/d/msgid/puppet-dev/CAHNFGkPCZHtfRoBB8rSt6ugj13yzkj7JQAbAqT0HQaK1SeJj-w%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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/CAOHkZxPLh7FH%2B%3DUpUKkpZGPjV0bcAPcD-MtCT53Fc5CwqUApEg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
