yes i kind of do that too. Eg if i have different classes that permit
to setup and install each a certain java, and i want to make sure only
one of them can be instanciated with Puppet on a server at a time, i
make sure one of my ressources in each class has the name file { java:
name=>'real name', (...) } . This way, i'll have an error of
duplicate definition at runtime if someone try to include more than 1
class
On 9 déc, 16:58, Aaron Grewell <[email protected]> wrote:
> I suppose if you really want it to fail if more than one option class is
> used you could define a 'canary resource' that would be the same in each
> option class. Then you would get an error if you tried to use more than
> one. The thing is, you would still have to document why you did that since
> it's non-obvious. Better to just document that only one should be used I
> suspect.
> On Dec 9, 2011 6:16 AM, "jcbollinger" <[email protected]> wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 8, 5:05 pm, Len Rugen <[email protected]> wrote:
> > > I have a group of classes (about 6 now) that I want to allow a host to
> > use
> > > none or at most one of them. This just a "guard rail" for admins. :-)
>
> > > Basically like this:
>
> > > base
> > > base::opt1
> > > base::opt2
> > > ...
> > > base::opt6
>
> > > base is default to all nodes.
>
> > > We use Puppet and Foreman :-)
>
> > So you want Puppet to *enforce* that nodes have at most one of the
> > base::optX classes? I'd recommend instead prominently documenting
> > that policy and verifying it in your QA process if it doesn't
> > naturally fall out of the classes themselves.
>
> > If you must do this, however, then you can structure the classes so
> > that they are mutually exclusive. Here's a trivial example:
>
> > class base::opt1 {
> > notify { 'base::option': message => 'opt1' }
> > }
>
> > class base::opt2 {
> > notify { 'base::option': message => 'opt1' }
> > }
>
> > No node can include both of those classes, because catalog compilation
> > would fail on the duplicate Notify['base::option'] resource. You can
> > also approach the problem via class inheritance if it makes sense to
> > do so:
>
> > class base2 {
> > notify { 'base2::option': message => 'base' }
> > }
>
> > class base2::opt1 inherits base2 [
> > Notify['base2::option'] { message => 'opt1' }
> > }
>
> > class base2::opt1 inherits base2 [
> > Notify['base2::option'] { message => 'opt2' }
> > }
>
> > Nodes may then include (or not) base2, plus at most one of base2::opt1
> > and base2::opt2. If they try to include both of the subclasses then
> > catalog compilation will fail because of the conflicting overrides.
>
> > Either approach is much more sensible if there is at least one
> > resource that naturally fills the role of the Notify than if you need
> > an artificial one (such as in the examples). Indeed, if there is such
> > a natural fit, then you get the desired behavior for free.
>
> > Warning: there is a potential issue in all this if you foresee ever
> > changing which option is applies to a given node. If there is
> > imperfect overlap of the resources managed by the various option
> > classes, then switching from one to another can leave previously
> > managed resources unmanaged instead of removing them. That's by no
> > means particular to the kind of setup you asked about, but I attribute
> > to it a greater likelihood of being problematic for you.
>
> > 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.
--
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.
