On Dec 19, 2010, at 1:37 AM, Ken Barber wrote:
> Would be terrible - because I would lose the arguments if the package was
> defined elsewhere earlier. That would be dumb. Also - the reverse is true ...
> by defining your own package you may be ruining someone else's package
> definition which
Stefan - obviously my example doesn't include classes but I see what you
mean. It is an interesting topic :-). So here was my example:
if !defined(Package["foo"]) {
package {"foo": ensure => installed }
}
Now if I wanted to define a specific revision, trigger or behaviour I could
understand w
On Sat, Dec 18, 2010 at 11:46:50AM -0800, Ken Barber wrote:
> Can you elaborate?
>
> On Saturday, December 18, 2010 7:23:57 PM UTC, kc7zzv wrote:
> >
> >
> > On Dec 18, 2010, at 3:50 AM, Ken Barber wrote:
> >
> > > For the record, an alternative that I don't believe was mentioned is to
> > do som
Can you elaborate?
On Saturday, December 18, 2010 7:23:57 PM UTC, kc7zzv wrote:
>
>
> On Dec 18, 2010, at 3:50 AM, Ken Barber wrote:
>
> > For the record, an alternative that I don't believe was mentioned is to
> do something like:
> >
> > if !defined(Package["foo"]) {
> > package {"foo": ensu
On Dec 18, 2010, at 3:50 AM, Ken Barber wrote:
> For the record, an alternative that I don't believe was mentioned is to do
> something like:
>
> if !defined(Package["foo"]) {
> package {"foo": ensure => installed }
> }
In general this is a bad idea though. Mostly because it can surprise yo
For the record, an alternative that I don't believe was mentioned is to do
something like:
if !defined(Package["foo"]) {
package {"foo": ensure => installed }
}
ken.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, sen
Thanks everyone for the pointers. I've gone with the Virtual
Resources approach because (a) the description of them more or less
exactly matches my use case, and (b) because from a class perspective
I'm trying to follow the "is a web server" type of paradigm, and "is a
jre-jce" doesn't really work
That's a fair point, but I shy away from using variables in one class
to influence another as much as possible for two reasons. First is
Puppet's variable scope is confusing at best. Second is I like to have
my classes do actions on a specific bit of a system entirely within
themselves, so anything
On Fri, Dec 17, 2010 at 07:46:29AM -0800, luke.bigum wrote:
> Nigel's Virtual Resources is one way, this is another using only
> classes.
>
> You can put the base software in classes of their own and include
> these in your 'server classes'. Classes can be included multiple times
> on a node witho
Nigel's Virtual Resources is one way, this is another using only
classes.
You can put the base software in classes of their own and include
these in your 'server classes'. Classes can be included multiple times
on a node without causing errors.
You'll want something that looks like:
class jre-jc
10 matches
Mail list logo
