Puppet users - Apr 2008 - looking for a way to remove module interdependencies

Hello List,

i''m running into an issue with puppet where I don''t know how
to solve
correctly.

We''re managing applications and our monitoring (nagios) using puppet 
using the following schema:

class nagios {
   // ensure nrpe ist installed
   // export a host definition
   nagios::check { ''ping'': }
   nagios::check { ''load'': }
   ...
}

define nagios::check() {
   // export a check-definition for this host
}

class myApp {
   // do whatever the app requires
   nagios::check { ''myapp'': }
}

class puppet {
   // ensure puppet is configured correctly
   nagios::check { ''puppet'': }
}


then we define nodes:


node basenode {
   // do the usual stuff for this operatingsystem
   include puppet
}

// A normal system. Setup + Monitoring
node X inherits basenode {
   $nagios_parents = [ ''parenthost'' ]
   include nagios
   include myApp
}

// Setup only, no monitoring at all
node Y inherits basenode {
   include myApp
}

That leads to nagios being broken, because node Y includes checks, but 
the host itself is missing.

Workarounds i already thought of:
1. Define a requirement from the check-definition to the 
host-definition. This breaks the configuration for node Y because we 
don''t have a host-definition and don''t want to create one.

2. Use "if(defined(Class[nagios]))" or something like that inside of 
nagios::check to only create the exported resource if nagios is also 
included. However, the docs say that defined() is order-dependant (and I 
don''t know if I *really* understand what that means).
I guess the order for node X would be something like stuff from 
"basenode", then my own stuff (that''s what I''ve seen
with definedness of
variables) which leads to the nagios::check() in the puppet class not 
exporting a check (because upon evaluation of that class the nagios 
class is not loaded yet)

3. Write some nasty shellscripts that ensure the nagios checks are 
removed from the nagios configfile if a host is missing.

How do you solve things like that? I really appreciate any hint, because 
  this is really driving me mad.

Regards,
Andreas
-- 
Solvention
Egermannstr. 6-8
53359 Rheinbach

Tel: +49 2226 158179-0
Fax: +49 2226 158179-9

http://www.solvention.de
mailto:info@solvention.de

On Apr 17, 2008, at 6:53 AM, Andreas Rogge wrote:
> That leads to nagios being broken, because node Y includes checks,  
> but the host itself is missing.
>
> Workarounds i already thought of:
> 1. Define a requirement from the check-definition to the host- 
> definition. This breaks the configuration for node Y because we  
> don''t have a host-definition and don''t want to create
one.
>
> 2. Use "if(defined(Class[nagios]))" or something like that inside
of
> nagios::check to only create the exported resource if nagios is also  
> included. However, the docs say that defined() is order-dependant  
> (and I don''t know if I *really* understand what that means).
> I guess the order for node X would be something like stuff from  
> "basenode", then my own stuff (that''s what I''ve
seen with
> definedness of variables) which leads to the nagios::check() in the  
> puppet class not exporting a check (because upon evaluation of that  
> class the nagios class is not loaded yet)
This just means that the ''nagios'' class has to be evaluated
before the
class using this test.

Really, you can think of that as "evaluated_yet", rather than  
"defined".  Puppet can''t know whether something will be
evaluated,
only whether it already has.
>
> 3. Write some nasty shellscripts that ensure the nagios checks are  
> removed from the nagios configfile if a host is missing.
That would be pretty painful.
>
> How do you solve things like that? I really appreciate any hint,  
> because  this is really driving me mad.

I''d probably work to get the ordering right.  Not sure what other  
options are available; maybe have some top-level boolean that declares  
whether nagios is in use, but that seems roughly equivalent to just  
including the nagios class or not.

-- 
A motion to adjourn is always in order. --Robert Heinlein
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


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

Luke Kanies schrieb:
> I''d probably work to get the ordering right.  Not sure what other
> options are available; maybe have some top-level boolean that declares  
> whether nagios is in use, but that seems roughly equivalent to just  
> including the nagios class or not.
The problem is: i cannot get the ordering right. I have done stuff like 
that before. Ususally I just make resources virtual in the definition 
like this:

define foo::bar() {
   @file { ....:
     ....
     tag => ''whatever'',
   }
}

and then realize them in the class they "belong" to:
class foo {
   File <|tag == ''whatever''|>
}

however, as in this case the resources are already virtual (they''re 
exported), it seems to be impossible to make it work that way.
I also don''t have any idea how to make the ordering work right. Global 
variables don''t help me either, because I need it on a per-node basis. 
Where the host is already a descendant of a basenode which can (and 
will) contain classes which do a nagios::check.

I guess I could work around that if something like the following was 
possible:

define foo::bar() {
   @@file { ...:
     ...
   }
}

@foo::bar { ... }

and then in the class:
class foo {
   Foo::bar <||>
}

What I''d expect here is that Foo::bar <||> realizes the virtual
resource
based on the define which in turn creates (but not realizes) the 
exported File.

Is that already possible somehow? Should I file a feature request for that?

Is my approach described above (i.e. to add virtual resources that are 
realized by other classes) good practice anyway?


Thanks in advance,
Andreas

-- 
Solvention
Egermannstr. 6-8
53359 Rheinbach

Tel: +49 2226 158179-0
Fax: +49 2226 158179-9

http://www.solvention.de
mailto:info@solvention.de

On Apr 21, 2008, at 10:03 AM, Andreas Rogge wrote:
> What I''d expect here is that Foo::bar <||> realizes the
virtual
> resource based on the define which in turn creates (but not  
> realizes) the exported File.
>
> Is that already possible somehow? Should I file a feature request  
> for that?
I think this is now possible, as of 0.24.4 or so.
>
> Is my approach described above (i.e. to add virtual resources that  
> are realized by other classes) good practice anyway?

Can you provide more info about what you''re actually trying to do?

-- 
Don''t tell me how hard you work. Tell me how much you get done.
     -- James Ling
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
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,

first of all, sorry for the late answer.

Luke Kanies schrieb:
> On Apr 21, 2008, at 10:03 AM, Andreas Rogge wrote:
> 
>> What I''d expect here is that Foo::bar <||> realizes the
virtual
>> resource based on the define which in turn creates (but not  
>> realizes) the exported File.
> 
> I think this is now possible, as of 0.24.4 or so.
I haven''t had the time to try it, but it sounds like a good way to
solve
the issue. I''ll report my results when I find the time to try it.
> Can you provide more info about what you''re actually trying to do?
I''ll try to explain this with an example from our site. What we
actually
do for backup and selinux and is the following:

in the backup module:
class backup {
  ...
}

def backup::selection($path, $prescript = "", $postscript =
"") {
   @file { "/etc/backup/selection.d/$title":
     content => template(''backup/selection.erb''),
     tag => ''backup-selection-file'',
   }
}

in the rdiffbackup-module:
class rdiffbackup inherits backup {
   File <| tag == ''backup-selection-file'' |>
   // all the other stuff required for rdiff backup
   // which also
}

in the bacula-module:
class bacula inherits backup {
   File <| tag == ''backup-selection-file'' |>
   // all the other stuff required for a bacula agent

   // this doesn''t actually work, because i cannot yet
   // export the file resource to the correct host
}

in the selinux-module:
class selinux {
   Exec <| tag == ''selinux-boolean'' |>
}

def selinux::bool($value = ''on'') {
   @exec { "...":
     command => "setsebool $title $value",
     unless => "getsebool $title | grep -q ''$title -->
$value''",
     tag => "selinux-boolean",
   }
}

in the mysql-module:
class mysql {
   // whatever is required for mysql
   backup::selection { "mysql":
     path => "/var/tmp/backup/mysql",
     prescript => "puppet:///mysql/mysqldumpall.sh",
   }
   selinux::bool { "allow_user_mysql_connect":
     value => "on",
   }
}

on the nodes:
node A inherits basenode {
   include mysql
   include bacula
}

node B inherits basenode {
   include mysql
   include selinux
}

node C inherits basenode {
   include mysql
   include selinux
   include rdiffbackup
}

What that is good for (at least imho) is the following:
You can include selinux and backup configuration into your generic mysql 
module and depending on the node you configure you can choose whether 
selinux will be touched (by including the selinux class) or not and 
whether backup-configuration should take place and which backup system 
you want to use.

The actual benefit is that you implement classes as required without 
having external dependencies. However, these classes can still benefit 
by interacting with other classes being used.

So for example you can say: "if there''s selinux and we manage it
then
please also make the following setting" and "if there''s a
backup, please
include the following directory and run this script before actually 
doing that backup".
This way you can implement a class that benefits from backup without 
having to know if and how the nodes that use the class will be backed up 
(i.e. you gain benefit without generating a dependency to a specific 
implementation)

And after all the developer of the module usually knows what other stuff 
is required for his application to work correctly, so keeping things 
like backup-scripts inside the module seems to be a good idea.

-- 
Solvention
Egermannstr. 6-8
53359 Rheinbach

Tel: +49 2226 158179-0
Fax: +49 2226 158179-9

http://www.solvention.de
mailto:info@solvention.de