selecting a command in a provider based on class variable?

[Tim Mooney]

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?

The full version:

We have puppet 3.4.2 on master and all agents, generally from the
PuppetLabs packages for OpenSource puppet.

Red Hat has begun providing alternate (updated) versions of some packages
as part of its "Software Collections Library", aka SCL. If you have
a RHEL 6.5 system subscribed to the appropriate software collections
channel, it's entirely possible to have something like this:

$ rpm -q -f /usr/bin/mysql
mysql-5.1.73-3.el6_5.x86_64
$ rpm -q -f /opt/rh/mysql55/root/usr/bin/mysql
mysql55-mysql-5.5.36-1.1.el6.x86_64

For a provider that relies on the mysql command-line tool to accomplish
certain tasks, it's no longer a great solution to just do

commands :mysql => 'mysql'

I also don't want to just have it always use the binary from
/opt/rh/mysql55/root/usr/bin/mysql if it's present, since it's at least
conceivable that one might need to use a particular version of the client
when accessing a particular database.

The best idea I've come up with is to have the provider decide which
specific version of a command to use based on a variable that has already
been set in the class, but I haven't found any examples of providers that
do that. If anyone can point me at some prior art, I would greatly
appreciate it.

Thanks,

Tim
--
Tim Mooney Tim.M...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

[jcbollinger]

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

[Tim Mooney]

In regard to: [Puppet Users] Re: selecting a command in a provider based on...:

>
>
> 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.

Thanks John! That idea occurred to me over the weekend and you've
confirmed that it's a much better way to go.

Much appreciated,

[Nan Liu]

An example of pe_gem v.s. package built in ruby gem provider:
https://github.com/puppetlabs/puppetlabs-pe_gem

HTH,

Nan