On Friday, April 11, 2014 7:15:05 PM UTC-5, Tim Mooney wrote: > > > Hi All! > > The tl;dr version: > > Can anyone point me at an example of an existing provider that selects > a particular command based not on a facter fact or whether a particular > path exists, but instead on a variable from a puppet class? > >
No, and that's a poor idea. Providers should not have visibility into or dependency on the class declaring the resource provided for. If your provider is for a custom type, however, then it seems to me that the natural approach would be to add a parameter (not a property) to the type. Providers can easily access the parameter values of a resource instance; in fact, that's the entire purpose of parameters that are not properties. If you are writing custom providers for built-in types, however, then the best I can come up with is to write different flavors of the provider (with different names) to cover the specific cases you care about. That's quite consistent with provider nature -- their purpose is to represent and implement different ways of managing the same type of resource. Granted, you are talking about only slight differences, but that would make it easy for the multiple providers in question to share most of their implementation. Having multiple providers available, your resources need only use the 'provider' metaparameter to specify a particular one. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/144d1d20-c2d8-400a-9e1b-ca5a7dc4e084%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
