Puppet users - Jul 2011 - What is the best practice to clean up installed components on a node?

I am new to Puppet, here is a question that I hope to get some help
from the group:

- assume I have 2 nodes, vm1 and vm2;

- assume that I defined a class of node say, sg_node, that includes
components such as Apache and Postgres DB etc.

- in the nodes.pp file, we have
  node vm1 {
        include sg_node
  }

Now, I want to let vm2 to be the sg_node, which is easy. But how to
clean up vm1 so that it doesn''t have the components that sg_node
installed?

Thanks  a lot!

-- 
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.

Create a class called sg_node::disabled that inherits sg_node and
overrides all of it''s resources to "undo" them.  This usually
means
setting ''ensure =>absent'' (or ''undef'' if
applicable) for most
resources.  For execs, I usually set ''unless => true.''

Be sure to include the class on the nodes you want to clean up (e.g.
vm1).

On Jul 7, 3:13 pm, Haitao Jiang <jianghai...@gmail.com>
wrote:
> I am new to Puppet, here is a question that I hope to get some help
> from the group:
>
> - assume I have 2 nodes, vm1 and vm2;
>
> - assume that I defined a class of node say, sg_node, that includes
> components such as Apache and Postgres DB etc.
>
> - in the nodes.pp file, we have
>   node vm1 {
>         include sg_node
>   }
>
> Now, I want to let vm2 to be the sg_node, which is easy. But how to
> clean up vm1 so that it doesn''t have the components that sg_node
> installed?
>
> Thanks  a lot!
-- 
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.

I''ve always thought there should be an implicit X::disabled class that
gets included for every host where X isn''t included.

Then if I create said class, it gets automatically executed on all hosts that
don''t include X. As it is now, one still has to go through and add
X::disabled to every host, which is largely defeating the purpose of having a
X::disabled class in the first place. (That purpose, for those not paying
attention, is to make sure that things are in a known state, including services
*not* running where they shouldn''t be.)

d.


> Create a class called sg_node::disabled that inherits sg_node and
> overrides all of it''s resources to "undo" them.  This
usually means
> setting ''ensure =>absent'' (or
''undef'' if applicable) for most
> resources.  For execs, I usually set ''unless => true.''
> 
-- 
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.

What if you specify a resource as being disabled/uninstalled/etc by default?
On Jul 13, 2011 9:40 AM, "Darrell Fuhriman" <darrell@garnix.org>
wrote:
>
> I''ve always thought there should be an implicit X::disabled class
that
gets included for every host where X isn''t
included.
>
> Then if I create said class, it gets automatically executed on all hosts
that don''t include X. As it is now, one still has to go through and add
X::disabled to every host, which is largely defeating the purpose of having
a X::disabled class in the first place. (That purpose, for those not paying
attention, is to make sure that things are in a known state, including
services *not* running where they shouldn''t
be.)
>
> d.
>
>
>
>> Create a class called sg_node::disabled that inherits sg_node and
>> overrides all of it''s resources to "undo" them. This
usually means
>> setting ''ensure =>absent'' (or
''undef'' if applicable) for most
>> resources. For execs, I usually set ''unless =>
true.''
>>
>
> --
> 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 Jul 13, 11:39 am, Darrell Fuhriman <darr...@garnix.org>
wrote:
> I''ve always thought there should be an implicit X::disabled class
that gets included for every host where X isn''t included.
>
> Then if I create said class, it gets automatically executed on all hosts
that don''t include X.

It is not practical to do this even at resource level, because for
many resources it is unclear what the opposite resource would be.
Exec resources are the canonical example ("don''t run" is not
at all
the same thing as "reverse the changes produced by running").  There
are in fact issues with most, if not all, resource types because
Puppet does not keep track of the state before applying a resource.
Even if Puppet *did* track prior state, there would still be an issue
of choosing which of possibly many prior states to revert to.

To do this at class level is worse, because in addition to not knowing
how to reverse a class''s resources, it is very difficult in the
general case to determine even which resources would need to be
reversed.  Conditional statements, selectors, variables, virtual and
exported resources, and class parameters are some of the many things
that complicate the analysis.

And even if all the above could somehow be satisfactorily resolved,
there remains the problem that the concept is fundamentally flawed.
Declining to include a class simply cannot reliably be interpreted as
an intention to "unmanage" the resources managed by that class.  As
just one example, consider classes that are omitted because they are
inapplicable to the node in question: maybe they are for a different
OS than the node''s, or maybe they are one of a series of alternative
classes.

Furthermore, that analysis ignores the question of whether the
behavior described would be desirable even if it were possible.  It
would not be for me, as it would make writing classes a lot more
difficult.  I would have to be careful to write each class so that the
automatic opposite would also work, and I am confident that that would
not be trivial.

> As it is now, one still has to go through and add X::disabled to every
host, which is largely defeating the purpose of having a X::disabled class in
the first place. (That purpose, for those not paying attention, is to make sure
that things are in a known state, including services *not* running where they
shouldn''t be.)

I disagree.  The purpose of having an X::disabled is to define what
exactly you do want when you explicitly want to exclude X.  Which
nodes should have that state ensured is an entirely separate (and not
clear-cut) question.  "Unmanaged" may not be the state you want for
certain resources, but it is not inherently undesirable for all
resources.

It is yet another separate question how to achieve the correct casses
being included on each node.  For example, if you want X to be
disabled on every node where it is not enabled, then one alternative
is to invert the class inheritence: class X defines the *disabled*
state of X, and is included in a default node definition inherited by
all other node definitions.  Then a class X::enabled subclasses X and
overrides resources as necessary to establish the "enabled" state;
nodes that want X enabled include X::enabled.  That avoids explicitly
including a specific X class in every node declaration.

Alternatively, the issue is easily addressed if you use an external
node classifier.  Or you can indeed put one of X and X::(enabled|
disabled) in every node declaration if that is indeed what you want to
do.  Some would prefer the explicitness of that style.


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.

> 
> Puppet does not keep track of the state before applying a resource.
> Even if Puppet *did* track prior state, there would still be an issue
> of choosing which of possibly many prior states to revert to.
I''m not asking puppet to know what to do, which I agree is ridiculous.
I''m saying that if and only if I''ve defined X::disabled,
automatically run it on every host which does not include X. If X::disabled
isn''t defined, then don''t do anything.  Probably a better way
to think of it instead of X::disabled is that for ever class X there is an
implicitly defined not-X class, which is empty until I define it. For example:

class webserver {
	package {apache: ensure => installed}
	service {apache: ensure => running}
}
class !webserver {
	package {apache: ensure => absent}
}
class dnsserver {
	[...]
}

node "foo" {
 include webserver
}
node "bar" {
 include dnsserver
}

On node bar, !webserver would get executed, but because I haven''t
defined !dnsserver, node foo wouldn''t do anything related to dnsserver.
>> As it is now, one still has to go through and add X::disabled to every
host, which is largely defeating the purpose of having a X::disabled class in
the first place. (That purpose, for those not paying attention, is to make sure
that things are in a known state, including services *not* running where they
shouldn''t be.)
> 
> 
> I disagree.  The purpose of having an X::disabled is to define what
> exactly you do want when you explicitly want to exclude X.  Which
> nodes should have that state ensured is an entirely separate (and not
> clear-cut) question.  "Unmanaged" may not be the state you want
for
> certain resources, but it is not inherently undesirable for all
> resources.

I''m not sure I understand what you''re saying here. It is
perfectly reasonable to want to ensure that things which aren''t
webservers are, in fact, not running as webservers, If I want to leave a
particular resource unmanaged, then just don''t put anything in the !X
class (or the X class, for that matter).  Maybe we have different approaches to
how we manage resources, but I genuinely can''t think of an example of
where you would want some hosts to be X, some to be !X, and some to be unknown,
which is kind of what I think you''re saying here, because I
can''t think of anyway that "unmanaged" doesn''t mean
"unknown".

Darrell

-- 
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 Jul 14, 12:16 pm, Darrell Fuhriman <darr...@garnix.org>
wrote:
> > Puppet does not keep track of the state before applying a resource.
> > Even if Puppet *did* track prior state, there would still be an issue
> > of choosing which of possibly many prior states to revert to.
>
> I''m not asking puppet to know what to do, which I agree is
ridiculous. I''m saying that if and only if I''ve defined
X::disabled, automatically run it on every host which does not include X. If
X::disabled isn''t defined, then don''t do anything.  Probably a
better way to think of it instead of X::disabled is that for ever class X there
is an implicitly defined not-X class, which is empty until I define it. For
example:
>
> class webserver {
>         package {apache: ensure => installed}
>         service {apache: ensure => running}}
>
> class !webserver {
>         package {apache: ensure => absent}}
>
> class dnsserver {
>         [...]
>
> }
>
> node "foo" {
>  include webserver}
>
> node "bar" {
>  include dnsserver
>
> }
>
> On node bar, !webserver would get executed, but because I haven''t
defined !dnsserver, node foo wouldn''t do anything related to dnsserver.

That still isn''t sensible.  It simply is not safe to assume that the
absence of class X in a node''s catalog is a signal that X::disabled
should be included in that catalog.  For instance, suppose I have a
pair X, X::disabled of classes specific to OS X.  I don''t want *either
one* on my CentOS boxes.

Consider also what happens when X, Y, X::disabled, and Y::disabled all
exist, and Y::disabled includes X. Suppose that after Puppet''s initial
pass to choose which classes to include, it sees that neither X nor Y
is included, so it adds X::disabled and Y::disabled.  But Y::disabled
includes X, so X::disabled shouldn''t be included after all!  Or should
it?

> >> As it is now, one still has to go through and add X::disabled to
every host, which is largely defeating the purpose of having a X::disabled class
in the first place. (That purpose, for those not paying attention, is to make
sure that things are in a known state, including services *not* running where
they shouldn''t be.)
>
> > I disagree.  The purpose of having an X::disabled is to define what
> > exactly you do want when you explicitly want to exclude X.  Which
> > nodes should have that state ensured is an entirely separate (and not
> > clear-cut) question.  "Unmanaged" may not be the state you
want for
> > certain resources, but it is not inherently undesirable for all
> > resources.
>
> I''m not sure I understand what you''re saying here. It is
perfectly reasonable to want to ensure that things which aren''t
webservers are, in fact, not running as webservers,

No argument there.

> If I want to leave a particular resource unmanaged, then just
don''t put anything in the !X class (or the X class, for that matter).

Fair enough.  Your clarification of how you imagined the feature
working clears up that bit.

>  Maybe we have different approaches to how we manage resources, but I
genuinely can''t think of an example of where you would want some hosts
to be X, some to be !X, and some to be unknown, which is kind of what I think
you''re saying here, because I can''t think of anyway that
"unmanaged" doesn''t mean "unknown".

Classes specific to a particular OS are such an example with respect
to nodes running a different OS.  Dev and test boxes present a wide
variety of examples where looser management of some resources may be
desired than for production boxes.



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.

> 
> That still isn''t sensible.  It simply is not safe to assume that
the
> absence of class X in a node''s catalog is a signal that
X::disabled
> should be included in that catalog.  For instance, suppose I have a
> pair X, X::disabled of classes specific to OS X.  I don''t want
*either
> one* on my CentOS boxes.
Fair enough.  I habitually write classes with something like:
class foo {
    case $operatingsystem {
        default: { fail ("X is not implemented for $operatingsystem")
}
	centos {[...]}
        darwin: {[...]}
   }
  [....]
}

So your scenario wouldn''t affect me anyway. But I''m
anal-rententive that way. I can''t imagine why you *wouldn''t*
do that if you''re going to be running on more than one platform.

I actually wish puppet had a ''confine'' parameter for classes
like it does for custom facts. It would make it easier to avoid shooting
yourself in the foot.

  class foo {
    confine $kernel => [''Linux'',
''Darwin'']
  }

Anyway, it''s a problem, yes, but not an insurmountable one.

> Consider also what happens when X, Y, X::disabled, and Y::disabled all
> exist, and Y::disabled includes X. Suppose that after Puppet''s
initial
> pass to choose which classes to include, it sees that neither X nor Y
> is included, so it adds X::disabled and Y::disabled.  But Y::disabled
> includes X, so X::disabled shouldn''t be included after all!  Or
should
> it?
Well, in that situation the right answer would be that only X is included. How
much work that is to implement in the current puppet parser, I have no idea. But
that''s irrelevant to the question at hand.

Plus, why the hell would anyone want to do that? If you put includes into your
!X classes, you''ve clearly failed to understand the concept and should
be taken far away from any keyboards and put into a systems administration
re-education camp. I''d go so far as to say that any !X class could not
include another class at all. (And obviously !X classes could not be included
explicitly anywhere, since that''s also fundamentally missing the
point.)
> 
>>  Maybe we have different approaches to how we manage resources, but I
genuinely can''t think of an example of where you would want some hosts
to be X, some to be !X, and some to be unknown, which is kind of what I think
you''re saying here, because I can''t think of anyway that
"unmanaged" doesn''t mean "unknown".
> 
> 
> [...] Dev and test boxes present a wide
> variety of examples where looser management of some resources may be
> desired than for production boxes.

*shudder*  Down that path lies madness, if you ask me.  To my mind, either
something''s managed or it isn''t – there is no alternative that
doesn''t end in tears. But again, these things are easily solved by
saying something like:

class !foo {
  case $environment {
    default: { #do nothing }
   production: { # do stuff }
  }
}

Because then at least you''re forced to be explicit about what your
management policy is, even if that policy is "we let dev machines do
whatever they want to service foo".

But that''s because I want the puppet configs to be the first (and
ideally only) place I need to go to find out what a given system''s
state is. That''s why I automate in the first place. It''s also
the basis for my wanting a !X class – because currently I have no easy way of
knowing if node Y is running a webserver or not without logging into it and
checking. If I had a !webserver class, I could feel confident that node Y is not
a webserver just by looking at the puppet configs.

That''s good for security, good for auditing, good for performance, and
good for piece of mind. :)

Darrell

-- 
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 never heard of nmap, eh? If you want to start talking about security and
auditing, that''s a whole other can of worms.

It''s a bad idea to assume that Defined State and Actual State will
match.

Anyway, I think you''re forgetting that node state in Puppet is explicit
by
nature. What you''re asking for defies this.

If your node changes roles, reinstall the OS.

On Thu, Jul 14, 2011 at 4:48 PM, Darrell Fuhriman
<darrell@garnix.org>wrote:
>
> But that''s because I want the puppet configs to be the first (and
ideally
> only) place I need to go to find out what a given system''s state
is. That''s
> why I automate in the first place. It''s also the basis for my
wanting a !X
> class – because currently I have no easy way of knowing if node Y is
running
> a webserver or not without logging into it and checking. If I had a
> !webserver class, I could feel confident that node Y is not a webserver
just
> by looking at the puppet configs.
>
> That''s good for security, good for auditing, good for performance,
and good
> for piece of mind. :)
>
> Darrell
>
>  --
> 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 Jul 14, 2011, at 7:16 PM, Darrell Fuhriman wrote:
> ''m not asking puppet to know what to do, which I agree is
ridiculous. I''m saying that if and only if I''ve defined
X::disabled, automatically run it on every host which does not include X. If
X::disabled isn''t defined, then don''t do anything.  Probably a
better way to think of it instead of X::disabled is that for ever class X there
is an implicitly defined not-X class, which is empty until I define it. For
example:
> 
> class webserver {
> 	package {apache: ensure => installed}
> 	service {apache: ensure => running}
> }
> class !webserver {
> 	package {apache: ensure => absent}
> }
> class dnsserver {
> 	[...]
> }

I like this approach!

-- 
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 Jul 14, 6:48 pm, Darrell Fuhriman <darr...@garnix.org> wrote:

[...]
> So your scenario wouldn''t affect me anyway. But I''m
anal-rententive that way. I can''t imagine why you *wouldn''t*
do that if you''re going to be running on more than one platform.

It''s fine to *wish* for a feature that would make your life easier,
but it is unreasonable to expect such a feature to be implemented when
it carries with it serious technical and practical problems for people
who build their manifests differently than you do.  Puppet needs to do
a good job handling everything its DSL can express, explicitly or
implicitly, which is one reason why its semantics do not include
implicitly adding classes to catalogs, and probably never will.

> I actually wish puppet had a ''confine'' parameter for
classes like it does for custom facts. It would make it easier to avoid shooting
yourself in the foot.
>
>   class foo {
>     confine $kernel => [''Linux'',
''Darwin'']
>   }

I wouldn''t have a problem with that, but you can accomplish the same
thing now with a conditional around the whole class body.

> Anyway, it''s a problem, yes, but not an insurmountable one.

It depends on what you mean by ''insurmountable''.  If the DSL
suffered
from that problem then yes, users could avoid it by taking care to use
certain coding techniques, but that just treats the symptom.  The
underlying problem is that the DSL would contain additional traps for
unwary and inexperienced users, and it would be capable of expressing
undecidable declarations.  Moreover, adding the feature at this point
would require everybody to audit all their manifests for compatibility
with this behavior change.  People are fallible, so some breakage
*would* occur.

> > Consider also what happens when X, Y, X::disabled, and Y::disabled all
> > exist, and Y::disabled includes X. Suppose that after
Puppet''s initial
> > pass to choose which classes to include, it sees that neither X nor Y
> > is included, so it adds X::disabled and Y::disabled.  But Y::disabled
> > includes X, so X::disabled shouldn''t be included after all!
 Or should
> > it?
>
> Well, in that situation the right answer would be that only X is included.

Perhaps, but but what if also X::disbled includes Y?  Then it is
completely undeterminable which classes to include.  Real-life
manifests are unlikely to have such a tight mutually-contradictory
loop, but they might easily have one involving a longer chain.

> How much work that is to implement in the current puppet parser, I have no
idea. But that''s irrelevant to the question at hand.
>
> Plus, why the hell would anyone want to do that?

Why do you suppose they wouldn''t?  It''s entirely likely that
foo::disabled classes would often want to include other classes.  For
instance, if foo::disabled ensures Service[''foo''] stopped,
then it
must also ensure that Package[''foo-service''] is installed,
which is
accomplished by some other class in a sufficiently DRY manifest set.
Or if it ensures a different state of some configuration file than
does class foo, then it may need to manage the directory in which that
file lives, which again is likely to be in some other class.  Since it
is likely that foo::disabled classes will include other classes, it is
unreasonable to assume that cycles would never occur.

> If you put includes into your !X classes, you''ve clearly failed to
understand the concept and should be taken far away from any keyboards and put
into a systems administration re-education camp. I''d go so far as to
say that any !X class could not include another class at all. (And obviously !X
classes could not be included explicitly anywhere, since that''s also
fundamentally missing the point.)

I don''t think you''ve thought this all the way through.

> >>  Maybe we have different approaches to how we manage resources,
but I genuinely can''t think of an example of where you would want some
hosts to be X, some to be !X, and some to be unknown, which is kind of what I
think you''re saying here, because I can''t think of anyway that
"unmanaged" doesn''t mean "unknown".
>
> > [...] Dev and test boxes present a wide
> > variety of examples where looser management of some resources may be
> > desired than for production boxes.
>
> *shudder*  Down that path lies madness, if you ask me.  To my mind, either
something''s managed or it isn''t – there is no alternative that
doesn''t end in tears. But again, these things are easily solved by
saying something like:
>
> class !foo {
>   case $environment {
>     default: { #do nothing }
>    production: { # do stuff }
>   }
>
> }
>
> Because then at least you''re forced to be explicit about what your
management policy is, even if that policy is "we let dev machines do
whatever they want to service foo".

Your overall theme seems to be "there are ways to write manifests so
that the problems inherent in the proposed feature won''t bite
you."  I
generally agree, but I don''t find that sufficient justification for
adding a feature that introduces so many pitfalls.  Anyway, if it all
boils down to how you write manifests, then there are already ways you
can write manifests so that you get your desired behavior without DSL
changes (the inheritence-based approach I described in a previous
message, for one), or you can get an equivalent fairly easily if you
write your own ENC.

> But that''s because I want the puppet configs to be the first (and
ideally only) place I need to go to find out what a given system''s
state is. That''s why I automate in the first place. It''s also
the basis for my wanting a !X class – because currently I have no easy way of
knowing if node Y is running a webserver or not without logging into it and
checking. If I had a !webserver class, I could feel confident that node Y is not
a webserver just by looking at the puppet configs.

You never have any way of *knowing* whether node Y is running a
webserver other than logging in and checking, especially if you''re
speaking from a security perspective.

I don''t dispute that the feature you propose might make your life
easier, but it would make a lot of other people''s lives harder.  I
don''t think you appreciate the nature and scope of the difficulties
that would arise, and I don''t accept "just write your manifests
differently" as an adequate response to them.

> That''s good for security, good for auditing, good for performance,
and good for piece of mind. :)

I''m all for security, auditing, performance, and peace of mind. 
I''m
also for ease of use, reliability, and backwards compatibility.  And
world peace.  My considered opinion is that the proposed feature would
be a net loss.


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.

I don''t.
On Jul 16, 2011 8:59 AM, "Emiliano Gabrielli (aka AlberT)" <
emiliano.gabrielli@gmail.com> wrote:
>
> On Jul 14, 2011, at 7:16 PM, Darrell Fuhriman wrote:
>
>> ''m not asking puppet to know what to do, which I agree is
ridiculous. I''m
saying that if and only if I''ve defined X::disabled, automatically run
it on
every host which does not include X. If X::disabled isn''t defined, then
don''t do anything. Probably a better way to think of it instead of
X::disabled is that for ever class X there is an implicitly defined not-X
class, which is empty until I define it. For example:
>>
>> class webserver {
>> package {apache: ensure => installed}
>> service {apache: ensure => running}
>> }
>> class !webserver {
>> package {apache: ensure => absent}
>> }
>> class dnsserver {
>> [...]
>> }
>
>
> I like this approach!
>
> --
> 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.

>> I actually wish puppet had a ''confine'' parameter for
classes like it does for custom facts. It would make it easier to avoid shooting
yourself in the foot.
Wishes don''t get anyone anywhere.

Filed feature requests do however ;)

We''ve had a few conversations in the past about extending
"confine" to
classes as well. It''s a reasonably natural syntax for certain use
cases.
>>
>>   class foo {
>>     confine $kernel => [''Linux'',
''Darwin'']
>>   }
>
>
> I wouldn''t have a problem with that, but you can accomplish the
same
> thing now with a conditional around the whole class body.
jcbollinger has done a great job outlining the problems that this
automatic disabled-inclusion suggestion poses, and indeed the
conceptual problems with the underlying desire itself.

If you *really* want this you could implement it reasonably easily in
a custom external node classifier, but it''s rather unlikely this would
make it into core.

-- 
Nigel Kersten
Product Manager, Puppet Labs

Join us for PuppetConf
<http://www.bit.ly/puppetconfsig>
Sept 22/23 Portland, Oregon, USA.

-- 
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.

Wanted to contribute another case where this idea of trying to manage
"actual" has conceptual consequences.  As you roll out Puppet on a
unmanaged diverged infrastructure, you probably want to start identifying
commonalities between systems and defining them as policy via puppet.  If at
that point you want to define the inverse of that policy too, you''ll
break everything that doesn''t have a well-defined class yet that
describes it.  e.g. if you have a web server that''s diverged so far
from most other web servers that you can''t put it in your web class
yet, you''d want it to (temporarily) stay unmanaged by Puppet, not get
uninstalled.  Sure, if one of your clean boxes with Apache changed roles it
would be nice to have that *undone*, but you can do that by having it be outside
the scope of what is defined and then remove it manually.  Or rebuild from
scratch like Scott suggested! :-)

Hmm, lightbulb.

*Maybe* having a way to undo a class that had been once installed is
conceptually feasible, rather than defining as policy what !class looks like
which I believe is conceptually untenable.  What if a class that''s
installed and then is no longer defined in policy stays resident on the system
as a tombstone, and certain class resources can be marked as tombstone-cleanup,
and when a class switches to a tombstone, each of those tombstone-cleanup
resources has to switch to ensured or executed success for the tombstone to go
away completely (if a class had no tombstone-cleanup resources, than it would be
directly removed).

Hmm, of course the mere idea of having class-was-here-now-its-not cleanup
functions is inherently divergent instead of convergent---you''re just
doing run-once actions---and so maybe shouldn''t exist in Puppet.  *What
if* Puppet left a fact on the system of tombstoned classes (and/or
resources)---that is resources/classes which had been once converged but were no
longer)---then a sysadmin could use a non-convergent tool like mc to carry out
actions that they determined they wanted done to clean up a tombstone from a
system, and somehow as a result the fact also would be updated to represent that
there was no more tombstone for that class/resource?  (I''m not going to
submit this as a feature request because at the moment I don''t really
need it ... I''m just suggesting it to promote discussion on the idea.) 
That way you can undo what Puppet does without dealing with "I''m
defining what ''not webserver'' looks like across
*everything*".

Eric

-- 
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.