Thanks very much for such a thorough and helpful response. I appreciate
it.
--
Biltong
bilt...@fastmail.fm
On Thu, May 17, 2012, at 06:44 AM, jcbollinger wrote:
>
>
> On May 17, 4:19 am, Biltong <bilt...@fastmail.fm> wrote:
> > Many thanks for your reply, unfortunately I'm quickly getting into a
> > mess:
> >[...]
> > On Wed, May 16, 2012, at 07:58 AM, jcbollinger wrote:
> >
> > > On May 15, 9:32 am, Biltong <bilt...@fastmail.fm> wrote:
> > > > I have a class that pulls in some yum repositories. One of the yum
> > > > repositories is disabled, but on one host I'd like to enable it.
> >
> > > > i.e. I'd like to do something like this:
> >
> > > > class { 'myyumrepos': }
> > > > yumrepo { 'EPEL': enabled => 1, }
> >
> > > > What's the best way to do this?
> >
> > > > I am using an ENC.
> >
> > > Closest to what you actually wrote might be
> >
> > > class myyumrepos::epel_enabled inherits myyumrepos {
> > > Yumrepo['EPEL'] { enabled => 1 }
> > > }
> >
> > > include 'myyumrepos::epel_enabled'
> >
> > My problem ehre is that I would need an myyumrepos::epel_enabled and an
> > myyumrepos::epel_disabled, which seems very counter-intuitive (and with
> > a lot of repetition for each other repository).
>
>
> No, you would need only the 'myyumrepos' class you already have, plus
> the subclass I wrote. You could safely apply the former to every
> node, PLUS apply the latter to those nodes for which you want EPEL
> enabled. As I said, very similar to what you actually wrote.
>
>
> > What I'd like is to do define some defaults like this:
> > 'EPEL'
> > enabled 1
> > gpgcheck 0
> > baseurlhttp://internal/EPEL
> > 'OMGREPO'
> > enabled 0
> > gpgcheck 1
> > baseurlhttp://internal/OMGREPO
> >
> > then to enable it, but changing those defaults:
> >
> > myrepos::repo {
> > 'EPEL'
> > enabled 0
> > 'OMGREPO'
> > enabled 1
> > gpgcheck 0
> >
> > }
> >
> > **note: syntax removed above**
> >
> > The alternative is to put the repo name, enabled flag, baseurl, gpgcheck
> > flag in each node manifest, which is also not good.
> >
> > > Better, however, might be for class myyumrepos to rely on an external
> > > data source (e.g. via hiera) to choose the correct 'enabled' value for
> > > each repo in the first place:
> >
> > > # (in class myyumrepos)
> > > yumrepo { 'EPEL':
> > > # ...
> > > enabled => hiera('EPEL_enabled')
> > > # ...
> > > }
> >
> > I can see this as being better, but it seems like a work around for not
> > being able to represent (or think of a way to represent) the information
> > above in puppet.
>
>
> The prevailing sentiment is that it is much better to separate your
> node- and site-specific data from your manifests. Those who hold that
> sentiment would consider the hiera approach inherently superior to
> what you seem to be asking for, not a work around at all.
> Nevertheless, read on.
>
>
> > I'd end up with a boolean for every repo, and the other
> > options for each repo.
>
>
> Any way around, you need to record every option value somewhere.
> Recording them in a hiera-served data store does not need to increase
> the volume of data or require needless duplication, and it is more
> flexible.
>
>
> > Is there a way to do this without hiera, like
> > using the imaginary syntax above?
>
>
> There are two main approaches to configuration parameters that vary
> from node to node:
>
> 1) Set default values, then override where desired, OR
> 2) Set the desired values in the first place via some dynamic means
>
> They can be used in various combinations.
>
> Puppet provides two mechanisms for overriding resource properties:
> 1a) Subclasses can override the properties of resources declared by
> their superclasses. We already talked about that.
> 1b) The properties of virtual of exported resources can be overridden
> when they are collected:
>
> class myclass {
> @notify { 'example': message => 'default' }
> }
>
> (elsewhere)
>
> Notify<| title == 'example' |> {
> message => 'override'
> }
>
> As I recently wrote in another thread, that's mildly evil. I'd
> characterize even the subclass approach as slightly naughty, though
> there is at least one reasonable usage pattern for it. Both stand a
> chance of causing you trouble later, though I'd rate the collection-
> override approach as a bit more risky.
>
> On the other side, Puppet provides a wide variety of means to set
> resource parameters correctly in the first place. Hiera can be used
> for that purpose in various ways. You can also use conditional logic
> in your classes based on node facts, global variables, or class
> variables from other classes (e.g. some kind of parameters class).
>
> Or you can use parameterized classes. I don't care much for these, as
> there are significant problems attending them (at least until the next
> Puppet major release). I rarely recommend them to anyone, and I don't
> recommend them to you. Nevertheless, you may find them to your
> liking. It might look like this:
>
> # definition
> class repos::epel($enabled => 1, $gpgcheck => 0, $baseurl => 'http://
> internal/epel') {
> yumrepo { 'epel':
> enabled => $enabled,
> gpgcheck => $gpgcheck,
> baseurl => $baseurl
> }
> }
>
> # declaration (somewhere else) providing a non-default value for the
> 'enabled' parameter
> class { 'repos::epel':
> enabled => 0
> }
>
>
> Again, I recommend avoiding use of parameterized classes with any
> currently available version of Puppet. Lots of people use them
> anyway, however.
>
>
> John
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
http://www.fastmail.fm - A no graphics, no pop-ups email service
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
