FAQ
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.mooney@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

--
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 puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/alpine.SOC.2.11.1404111843100.17447%40dogbert.cc.ndsu.NoDak.edu.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Jcbollinger at Apr 14, 2014 at 2:59 pm

    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 puppet-users+unsubscribe@googlegroups.com.
    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.
  • Tim Mooney at Apr 14, 2014 at 6:54 pm
    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,

    Tim
    --
    Tim Mooney tim.mooney@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

    --
    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 puppet-users+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/alpine.SOC.2.11.1404141351490.17447%40dogbert.cc.ndsu.NoDak.edu.
    For more options, visit https://groups.google.com/d/optout.
  • Nan Liu at Apr 16, 2014 at 4:52 pm

    On Fri, Apr 11, 2014 at 7:15 PM, Tim Mooney wrote:
    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.
    An example of pe_gem v.s. package built in ruby gem provider:
    https://github.com/puppetlabs/puppetlabs-pe_gem

    HTH,

    Nan

    --
    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 puppet-users+unsubscribe@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACqVBqD06H9mha4A4TAQXActPau1HGdCzHgfT%2B_BJxP8UhNHag%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 12, '14 at 12:15a
activeApr 16, '14 at 4:52p
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase