On May 17, 4:19 am, Biltong <[email protected]> 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 <[email protected]> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
