Puppet users - Mar 2011 - How to remove a class from a node (using dashboard)

Dear all,

I finally managed to load an extra module (apache) via dashboard but
i''m having trouble removing it?
My expectation was that, once i removed the class from the node
(stopped including it), Puppet would call some sort of deprovisioning
mechanism that would remove the class (so, in my case, when i stopped
including the apache class in my node, puppet would remove apache from
my node).

According to my tests, that did not happen (Apache is still up and running).
What are the best practices to remove a module when we no longer need it?

Thanks,
Luis

-- 
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 will not do anything you don''t tell it to do. Try think of it
more along the lines of your modules and manifests describing how a
server should be and only how it should be. So if you don''t tell it
NOT to be something, it''s just going to ignore anything else that
exists on the system - this is why you haven''t needed to tell Puppet
to install the packages kernel, and core-utils, it''s not going to undo
anything that already exists that it doesn''t know about otherwise
Puppet manifests would be massively redundant :)

A lot of people follow the convention of using an inherited class like
apache::disabled that shuts down everthing that the class apache does:

class apache {
  package { "httpd": ensure => present }
  service { "httpd": ensure => running }
}

class apache::disabled inherits apache {
  Package["httpd"] { ensure => absent }
  Service["httpd"] { ensure => stopped }
}

node never_be_a_web_server {
  include apache::disabled
}

On Mar 2, 4:42 am, Luis Miguel Silva
<luismiguelferreirasi...@gmail.com> wrote:
> Dear all,
>
> I finally managed to load an extra module (apache) via dashboard but
> i''m having trouble removing it?
> My expectation was that, once i removed the class from the node
> (stopped including it), Puppet would call some sort of deprovisioning
> mechanism that would remove the class (so, in my case, when i stopped
> including the apache class in my node, puppet would remove apache from
> my node).
>
> According to my tests, that did not happen (Apache is still up and
running).
> What are the best practices to remove a module when we no longer need it?
>
> Thanks,
> Luis
-- 
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.

Thanks Luke, that helps clarify things for me :o)

Luis Miguel Silva

On Mar 2, 2011, at 2:29 AM, "luke.bigum"
<luke.bigum@fasthosts.co.uk> wrote:
> Puppet will not do anything you don''t tell it to do. Try think of
it
> more along the lines of your modules and manifests describing how a
> server should be and only how it should be. So if you don''t tell
it
> NOT to be something, it''s just going to ignore anything else that
> exists on the system - this is why you haven''t needed to tell
Puppet
> to install the packages kernel, and core-utils, it''s not going to
undo
> anything that already exists that it doesn''t know about otherwise
> Puppet manifests would be massively redundant :)
> 
> A lot of people follow the convention of using an inherited class like
> apache::disabled that shuts down everthing that the class apache does:
> 
> class apache {
>  package { "httpd": ensure => present }
>  service { "httpd": ensure => running }
> }
> 
> class apache::disabled inherits apache {
>  Package["httpd"] { ensure => absent }
>  Service["httpd"] { ensure => stopped }
> }
> 
> node never_be_a_web_server {
>  include apache::disabled
> }
> 
> On Mar 2, 4:42 am, Luis Miguel Silva
> <luismiguelferreirasi...@gmail.com> wrote:
>> Dear all,
>> 
>> I finally managed to load an extra module (apache) via dashboard but
>> i''m having trouble removing it?
>> My expectation was that, once i removed the class from the node
>> (stopped including it), Puppet would call some sort of deprovisioning
>> mechanism that would remove the class (so, in my case, when i stopped
>> including the apache class in my node, puppet would remove apache from
>> my node).
>> 
>> According to my tests, that did not happen (Apache is still up and
running).
>> What are the best practices to remove a module when we no longer need
it?
>> 
>> Thanks,
>> Luis
> 
> -- 
> 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 Mar 2, 3:29 am, "luke.bigum" <luke.bi...@fasthosts.co.uk>
wrote:
> Puppet will not do anything you don''t tell it to do. Try think of
it
> more along the lines of your modules and manifests describing how a
> server should be and only how it should be.
That point deserves emphasis, for it is one of the keys to
understanding Puppet and using it effectively.  Many Puppet newbies
think of Puppet as if it were a scripting engine with an obtuse
syntax.  This thought pattern is reflected by questions framed as "How
do I tell Puppet to _do_ XYZ?"

In fact, Puppet is a state management service with an instruction
syntax geared specifically to that role.  Questions framed as "How do
I tell Puppet that the node should (not) _be_/_have_ UVW?" reflect a
clearer understanding.

My #1 rule of Puppet is "Puppet is not a script engine."
>   So if you don''t tell it
> NOT to be something, it''s just going to ignore anything else that
> exists on the system - this is why you haven''t needed to tell
Puppet
> to install the packages kernel, and core-utils, it''s not going to
undo
> anything that already exists that it doesn''t know about otherwise
> Puppet manifests would be massively redundant :)
Of course you *can* specify, for example, an exhaustive list of the
packages that should be installed.  If you do so, you can even tell
Puppet that no unlisted packages should be present (see the
"Resources" resource).  Ditto for other resource types.  Few people
seem to adopt such a locked-down approach, however.

My #2 rule of Puppet is "Unmanaged means ''I don''t
care''."  The
corrolary is "Say ''absent'' when that''s what you
want."


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.

Yeah, that''s good to know.
I figured that was the way it worked after i removed the class from
the node and the service stood there BUT was assuming that it would go
away (i.e. the class had a unprovisioning method of some sort) :o).

Thanks a lot,
Luis

On Wed, Mar 2, 2011 at 8:29 AM, jcbollinger <John.Bollinger@stjude.org>
wrote:
>
>
> On Mar 2, 3:29 am, "luke.bigum"
<luke.bi...@fasthosts.co.uk> wrote:
>> Puppet will not do anything you don''t tell it to do. Try think
of it
>> more along the lines of your modules and manifests describing how a
>> server should be and only how it should be.
>
> That point deserves emphasis, for it is one of the keys to
> understanding Puppet and using it effectively.  Many Puppet newbies
> think of Puppet as if it were a scripting engine with an obtuse
> syntax.  This thought pattern is reflected by questions framed as "How
> do I tell Puppet to _do_ XYZ?"
>
> In fact, Puppet is a state management service with an instruction
> syntax geared specifically to that role.  Questions framed as "How do
> I tell Puppet that the node should (not) _be_/_have_ UVW?" reflect a
> clearer understanding.
>
> My #1 rule of Puppet is "Puppet is not a script engine."
>
>>   So if you don''t tell it
>> NOT to be something, it''s just going to ignore anything else
that
>> exists on the system - this is why you haven''t needed to tell
Puppet
>> to install the packages kernel, and core-utils, it''s not going
to undo
>> anything that already exists that it doesn''t know about
otherwise
>> Puppet manifests would be massively redundant :)
>
> Of course you *can* specify, for example, an exhaustive list of the
> packages that should be installed.  If you do so, you can even tell
> Puppet that no unlisted packages should be present (see the
> "Resources" resource).  Ditto for other resource types.  Few
people
> seem to adopt such a locked-down approach, however.
>
> My #2 rule of Puppet is "Unmanaged means ''I don''t
care''."  The
> corrolary is "Say ''absent'' when that''s what
you want."
>
>
> 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.