I believe this has already been discussed[1], but I''d like to add a bit
more to that original discussion and see if anyone has any suggestions.
Here''s what I''m trying to do: we have a set of very thorough
"wipe"
scripts that run every night on our workstations. I''d like to stash
these into a class so that I can include them as a group:
class wiped {
cron { "tmp1":
...
}
cron { "usr-tmp":
...
}
}
Then the class for our normal workstations:
class workstation {
include wiped
}
We have a handful of machines we use for development. We don''t want the
temp areas on these machines cleaned for a variety of reasons, so the
wipe scripts need to be disabled. Here was my first inclination:
class devstation inherits workstation {
Cron["tmp1"] { ensure => absent }
Cron["usr-tmp"] { ensure => absent }
}
This gives an error, though: devstation isn''t a subclass of wiped, so
it
can''t override wiped''s elements.
I also tried this variation:
class devstation inherits workstation {
Cron { ensure => absent }
}
but the cron entries still appeared.
I can think of one workaround, which is to remove wiped from
workstation and use workstation as a "mixin" rather than inheriting
from
it:
class workstation { ... }
class wiped { ... }
class devstation {
include workstation
}
node client1 {
include workstation
include wiped
}
node devbox1 {
include devstation
}
but I think I prefer the semantics of "inherits," since a devstation
is a
special kind of workstation, rather than a superset of it.
I''m curious to hear suggestions for implementing this sort of behavior,
and how other people are approaching similar problems.
[1]: http://mail.madstop.com/pipermail/puppet-dev/2006-May/000602.html
--
eric
Mr. Peden,
If I recall correctly, the problem that you are having is that the Cron type
will either add entries or remove all of the entries. Removing particular
entries is not currently supported.
Two approaches that I can think of are:
1) Create a different class for each cron job and only include the classes that
you want.
2) Create a template using ERB which includes the cron job text based on the
presence of various variables.
Number two is my preferred solution since it is more elegant and can be placed
into /etc/crontab or /etc/cron.X depending on your needs.
I hope that this helped,
-- Rob --
----- Original Message ----
From: Eric Peden <eric@ericpeden.com>
To: puppet-users@madstop.com
Sent: Tuesday, February 20, 2007 4:36:49 PM
Subject: [Puppet-users] overriding included classes
I believe this has already been discussed[1], but I''d like to add a bit
more to that original discussion and see if anyone has any suggestions.
Here''s what I''m trying to do: we have a set of very thorough
"wipe"
scripts that run every night on our workstations. I''d like to stash
these into a class so that I can include them as a group:
class wiped {
cron { "tmp1":
...
}
cron { "usr-tmp":
...
}
}
Then the class for our normal workstations:
class workstation {
include wiped
}
We have a handful of machines we use for development. We don''t want the
temp areas on these machines cleaned for a variety of reasons, so the
wipe scripts need to be disabled. Here was my first inclination:
class devstation inherits workstation {
Cron["tmp1"] { ensure => absent }
Cron["usr-tmp"] { ensure => absent }
}
This gives an error, though: devstation isn''t a subclass of wiped, so
it
can''t override wiped''s elements.
I also tried this variation:
class devstation inherits workstation {
Cron { ensure => absent }
}
but the cron entries still appeared.
I can think of one workaround, which is to remove wiped from
workstation and use workstation as a "mixin" rather than inheriting
from
it:
class workstation { ... }
class wiped { ... }
class devstation {
include workstation
}
node client1 {
include workstation
include wiped
}
node devbox1 {
include devstation
}
but I think I prefer the semantics of "inherits," since a devstation
is a
special kind of workstation, rather than a superset of it.
I''m curious to hear suggestions for implementing this sort of behavior,
and how other people are approaching similar problems.
[1]: http://mail.madstop.com/pipermail/puppet-dev/2006-May/000602.html
--
eric
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
____________________________________________________________________________________
Never Miss an Email
Stay connected with Yahoo! Mail on your mobile. Get started!
http://mobile.yahoo.com/services?promote=mail
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
On Tue, Feb 20, 2007 at 02:05:04PM -0800, Robert Mombro wrote:>If I recall correctly, the problem that you are having is that the Cron >type will either add entries or remove all of the entries. Removing >particular entries is not currently supported.That''s good to know, although now I''m afraid that I was too specific in describing my situation. I have the same problem even if the "cron" type isn''t used: I want to modify entries that are included by a parent class, rather than appearing in the parent class directly. I''ve actually created a custom "wipe" type to abstract away the exact mechanism used for cleaning (this is similar in concept to the existing "tidy" type, although we''re running on our script to determine what needs cleaning). Wiping might be implemented with a package, or an "exec", or a cron job. The problem is that I want to turn wiping off from a subclass of "workstation," but I want to define my wipes in a separate class rather than inling them into "workstation." I''m sure there is another way of looking at this that will make the "problem" go away, but I''m too deadset on my current approach to see it. ;)>1) Create a different class for each cron job and only include the >classes that you want. >2) Create a template using ERB which includes the cron job text based >on the presence of various variables. > >Number two is my preferred solution since it is more elegant and can be >placed into /etc/crontab or /etc/cron.X depending on your needs.This is also good to know. I suspect I''m missing a lot of opportunities to use templates, and this is a good (non-obvious) example of their use. Thanks. -- eric
class unwiped inherits wiped {
Cron["tmp1"] { ensure => absent }
Cron["usr-tmp"] { ensure => absent }
}
class devstation inherits workstation {
include unwiped
}
--On Tuesday, February 20, 2007 3:36 PM -0600 Eric Peden
<eric@ericpeden.com> wrote:
> I believe this has already been discussed[1], but I''d like to add
a bit
> more to that original discussion and see if anyone has any suggestions.
>
> Here''s what I''m trying to do: we have a set of very
thorough "wipe"
> scripts that run every night on our workstations. I''d like to
stash
> these into a class so that I can include them as a group:
>
> class wiped {
> cron { "tmp1":
> ...
> }
>
> cron { "usr-tmp":
> ...
> }
> }
>
> Then the class for our normal workstations:
>
> class workstation {
> include wiped
> }
>
> We have a handful of machines we use for development. We don''t
want the
> temp areas on these machines cleaned for a variety of reasons, so the
> wipe scripts need to be disabled. Here was my first inclination:
>
> class devstation inherits workstation {
> Cron["tmp1"] { ensure => absent }
> Cron["usr-tmp"] { ensure => absent }
> }
>
> This gives an error, though: devstation isn''t a subclass of wiped,
so it
> can''t override wiped''s elements.
>
> I also tried this variation:
>
> class devstation inherits workstation {
> Cron { ensure => absent }
> }
>
> but the cron entries still appeared.
>
> I can think of one workaround, which is to remove wiped from
> workstation and use workstation as a "mixin" rather than
inheriting from
> it:
>
> class workstation { ... }
> class wiped { ... }
> class devstation {
> include workstation
> }
> node client1 {
> include workstation
> include wiped
> }
> node devbox1 {
> include devstation
> }
>
> but I think I prefer the semantics of "inherits," since a
devstation is a
> special kind of workstation, rather than a superset of it.
>
> I''m curious to hear suggestions for implementing this sort of
behavior,
> and how other people are approaching similar problems.
>
> [1]: http://mail.madstop.com/pipermail/puppet-dev/2006-May/000602.html
--
Digant C Kasundra
// www.diggyk.com //
Mr. Peden,
Looking back at your original example, it appears that the problem is that you
do not maintain inheritance throughout your chain.
For example, you wrote:
class wiped {
cron { "tmp1":
...
}
cron { "usr-tmp":
...
}
}
class workstation {
include wiped
}
class devstation inherits workstation {
Cron["tmp1"] { ensure => absent }
Cron["usr-tmp"] { ensure => absent }
}
This should read as follows to do what I believe you are trying to accomplish:
class wiped {
cron { "tmp1":
...
}
cron { "usr-tmp":
...
}
}
# The following maintains inheritance down the class hierarchy while include
directives do not allow overrides.
class workstation inherits wiped {
....
}
class devstation inherits workstation {
Cron["tmp1"] { ensure => absent }
Cron["usr-tmp"] { ensure => absent }
}
I hope that this helped,
-- Rob --
----- Original Message ----
From: Eric Peden <eric@ericpeden.com>
To: Puppet User Discussion <puppet-users@madstop.com>
Sent: Tuesday, February 20, 2007 5:22:37 PM
Subject: Re: [Puppet-users] overriding included classes
On Tue, Feb 20, 2007 at 02:05:04PM -0800, Robert Mombro
wrote:>If I recall correctly, the problem that you are having is that the Cron
>type will either add entries or remove all of the entries. Removing
>particular entries is not currently supported.
That''s good to know, although now I''m afraid that I was too
specific in
describing my situation. I have the same problem even if the "cron"
type
isn''t used: I want to modify entries that are included by a parent
class, rather than appearing in the parent class directly.
I''ve actually created a custom "wipe" type to abstract away
the exact
mechanism used for cleaning (this is similar in concept to the existing
"tidy" type, although we''re running on our script to
determine what
needs cleaning). Wiping might be implemented with a package, or an
"exec", or a cron job.
The problem is that I want to turn wiping off from a subclass of
"workstation," but I want to define my wipes in a separate class
rather
than inling them into "workstation." I''m sure there is
another way of
looking at this that will make the "problem" go away, but I''m
too
deadset on my current approach to see it. ;)
>1) Create a different class for each cron job and only include the
>classes that you want.
>2) Create a template using ERB which includes the cron job text based
>on the presence of various variables.
>
>Number two is my preferred solution since it is more elegant and can be
>placed into /etc/crontab or /etc/cron.X depending on your needs.
This is also good to know. I suspect I''m missing a lot of opportunities
to use templates, and this is a good (non-obvious) example of their
use. Thanks.
--
eric
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight''s Picks" on Yahoo! TV.
http://tv.yahoo.com/
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
On Feb 20, 2007, at 10:05 PM, Robert Mombro wrote:> Mr. Peden, > > If I recall correctly, the problem that you are having is that the > Cron type will either add entries or remove all of the entries. > Removing particular entries is not currently supported.It sounds like the real culprit has been tracked down (the inheritance chains), but for the record, removing particular cron jobs is definitely supported, it just might not work. There''s a bug saying it doesn''t work on FreeBSD, but I don''t have corresponding reports for any other platforms. -- The chief lesson I have learned in a long life is that the only way to make a man trustworthy is to trust him; and the surest way to make him untrustworthy is to distrust him and show your distrust. -- Henry L. Stimson --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Tue, Feb 20, 2007 at 02:40:21PM -0800, Robert Mombro wrote:>Looking back at your original example, it appears that the problem is >that you do not maintain inheritance throughout your chain.<snip>> class workstation inherits wiped { > .... > > }Hrmm... the semantics of this still bothers me, since it implies that workstation is a specialization of wiped, which isn''t really the case. Being wiped is an attribute of workstation, not a specilization. This would also break if workstation needed to inherit from another class. That said, it does solve the problem. ;) My thanks to the both of you who offerred this solution; I''m off to go put it into practice. -- eric
--On Wednesday, February 21, 2007 11:08 AM -0600 Eric Peden <eric@ericpeden.com> wrote:> On Tue, Feb 20, 2007 at 02:40:21PM -0800, Robert Mombro wrote: >> Looking back at your original example, it appears that the problem is >> that you do not maintain inheritance throughout your chain. > <snip> >> class workstation inherits wiped { >> .... >> >> } > > Hrmm... the semantics of this still bothers me, since it implies that > workstation is a specialization of wiped, which isn''t really the case. > Being wiped is an attribute of workstation, not a specilization. This > would also break if workstation needed to inherit from another class. > > That said, it does solve the problem. ;) My thanks to the both of you > who offerred this solution; I''m off to go put it into practice.Did you not like my solution? I think this looks more logical: class unwiped inherits wiped { Cron["tmp1"] { ensure => absent } Cron["usr-tmp"] { ensure => absent } } class devstation inherits workstation { include unwiped } -- Digant C Kasundra // www.diggyk.com //
On Wed, Feb 21, 2007 at 02:43:55PM -0800, Digant C Kasundra wrote:>--On Wednesday, February 21, 2007 11:08 AM -0600 Eric Peden >> Hrmm... the semantics of this still bothers me, since it implies that >> workstation is a specialization of wiped, which isn''t really the case.<snip>>Did you not like my solution? I think this looks more logical: > >class unwiped inherits wiped { [...] }My apologies! I hadn''t read your mail carefully the first time; this indeed addresses my semantic concerns. In fact, it''s even more descriptive than what I originally had in mind. Thanks! -- eric