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 :-) Thanks -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi,
The way we do as similar kind of thing is use a ''role'' class
which assigns various classes based on the fact of a node.
We created a custom fact that gives a fact that tells us the node''s
role. We then use:
if $role-fact =~ role { include variousclasses }
Not as simple as that obviously but I hope that gives the point.
In your node declaration you can use similar syntax to include or exclude
classes.
Hope that helps,
Den
On 09/12/2011, at 10:05, Len Rugen <lenrugen@gmail.com> 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 :-)
>
> Thanks
> --
> 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+unsubscribe@googlegroups.com.
> 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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Dec 8, 5:05 pm, Len Rugen <lenru...@gmail.com> 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Aaron Grewell
2011-Dec-09 15:58 UTC
Re: [Puppet Users] Re: Any way to have exclusive classes?
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" <John.Bollinger@stjude.org> wrote:> > > On Dec 8, 5:05 pm, Len Rugen <lenru...@gmail.com> 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 puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com. > 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 puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 <aaron.grew...@gmail.com>
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"
<John.Bollin...@stjude.org> wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 8, 5:05 pm, Len Rugen <lenru...@gmail.com> 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 puppet-users@googlegroups.com.
> > To unsubscribe from this group, send email to
> > puppet-users+unsubscribe@googlegroups.com.
> > 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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Felix Frank
2011-Dec-13 12:53 UTC
Re: [Puppet Users] Re: Any way to have exclusive classes?
On 12/13/2011 10:33 AM, Alexandre wrote:> This way, i''ll have an error of > duplicate definition at runtime if someone try to include more than 1 > class...which can be a little counter-intuitive to the uninitiated, I presume. If you want to be a little more abusive in terms of puppet style, but put emphasis on expressive error messages, include this in each class: if defined(Class["a"]) or defined(Class["b"]) or ... { fail "including more than on of class a, b, ... is forbidden" } Again: This is terrible style, but it''ll do the job (and subjectively, the canary resource strikes me as a bit of a hack itself, too). Cheers, Felix -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.