On Monday, July 29, 2013 1:38:17 PM UTC-5, Stephen Brown II wrote:
>
> Greetings all,
>
> I have a feeling I'm trying to be a bit too clever for my own good, or
> making the mistake of treating the declarative language as a procedural.
> But at any rate, here is my issue.
>
> I would like to set up a params class ( in the style of
> http://docs.puppetlabs.com/guides/parameterized_classes<http://docs.puppetlabs.com/guides/parameterized_classes.html#appendix-smart-parameter-defaults>
> ) for
> installing mariadb on any operating system that is supported by the
> official mariadb.org repository configuratior:
> https://downloads.mariadb.org/mariadb/repositories/
>
> However, I've noticed that not all versions of MariaDB are available for
> all OS releases. For the most part, 5.5 and 10.0 are available, but for
> older versions of Ubuntu /(hardy|maverick|natty|oneiric)/, only 5.2 and 5.3
> are available.
>
> Here is the gist of my params.pp as it stands:
> https://gist.github.com/StephenBrown2/6106113
>
> What I would eventually like to get working is the ability for the module
> to set a reasonable default, and also allow for overriding in the calling,
> but if the operating system doesn't support that MariaDB release version,
> to use the latest available release instead.
>
> For example, this should work fine:
>
> class { 'maria': }
>
> This should also work:
>
> class { 'maria':
> version => '5.5',
> }
>
> both resulting in mariadb 5.5 being installed on anything but those older
> ubuntu's. in which case, Puppet would throw a warning and set $version
> instead to '5.3'.
>
>
I think that's a lousy idea. It's very counterintuitive for the class to
accept data telling it what version to use, and then to use a different
version instead. At minimum, name the parameter so that it better reflects
its function (e.g. maybe "preferred_version"), but even then I'm not very
fond of the idea. I don't see a good use case. If you don't care which
version is installed on any given machine, then why is it worthwhile to
specify even a preferred version?
> Similarly, if this was specified:
>
> class { 'maria':
> version => '5.3',
> }
>
> on a Debian 7 system, I'd expect it to come back as '10.0'. But this might
> be where the cleverness could be a liability.
>
> Might I have to simply set the default version for each possible
> operatingsystem value? I would hope not, as that seems a bit unweildy, but
> maybe necessary since variables can only be declared once per scope (
> http://docs.puppetlabs.com/learning/variables<http://docs.puppetlabs.com/learning/variables.html#variables>
> : "You can only assign the same variable *once* in a given scope." )
>
> Please let me know if I've been unclear, or enlighten me if this is going
> down the wrong path.
>
>
The values of class parameters are set by the first-parsed declaration of
the class, taking into account any explicit data bindings, hiera data
bindings, and default values, but not anything in the class body.
Parameter values do not thereafter change for the duration of the catalog
run. You could, however, have additional class variables. For example,
you might have $maria::preferred_version (a parameter) and
$maria::selected_version (an ordinary class variable). I'm not convinced
that's a good idea, but at least it would be clear.
An alternative would be to compute a default version, perhaps in a ::params
class, based on the node facts. Use that version if the user does not
specify a different one, but otherwise defer to the user. I'd be inclined
to simply allow application of the catalog to fail if an unsupported
version is specified (which also lets it succeed without you changing
anything if the available versions on for the target platform change). If
you want to validate, however, then do so, failing the catalog if an
invalid version is specified.
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+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
