I've been playing with puppet for a couple of weeks and that's how I
have configured it:
# ls /etc/puppet/manifests/
modules site.pp
# ls /etc/puppet/manifests/modules/
autofs_home fstab local_conf local_groups local_users packages pbs_client repos yaim
and each "module" is auto-descriptive... At this point are only
classes, but in a near future, they can become a combination of
classes/definitions.
Is this correct? or is better to just include all *pp files in manifest
dir?
My other question, is posible to add some "dependencies" between
imports?
# cat site.pp
import "autofs_home"
import "fstab"
import "local_conf"
import "packages"
import "pbs_client"
import "repos"
import "yaim"
import "local_groups"
import "local_users"
node default{
include pbs_client
include autofs_home
include fstab
include local_conf
include packages
include pbs_client
include repos
include yaim
include local_groups
include local_users
}
I need some order between groups/user/yaim and packages/pbs, for
exmaple.
Do I have to define dependencies in classes?
If yes, may I call a resource defined in a module from another
diferntet?
TIA,
Arnau
It is a really good idea to start using modules from the very beginning.
> My other question, is posible to add some "dependencies" between
> imports?
You can't define dependencies between imports. Import is a function, not a type.
> I need some order between groups/user/yaim and packages/pbs, for
> exmaple.
>
> Do I have to define dependencies in classes?
You must define dependencies at the "resource" level (though you can
also define dependencies on defined types and classes; in this way you
are using them as resources).
> If yes, may I call a resource defined in a module from another
> diferntet?
Resources are essentially global; you may refer to them from any module.
I think you might want to take a step back and really think about how
you want to make the best use of puppet. Make sure your modules
represent logical chunks of configuration, rather than just grouping
together all the resources that are similar. Why have a 'packages'
module? If I were trying to configure an LDAP server, I wouldn't want
to have the user in a 'system_users' module, the package(s) in
'packages' and the startup scripts in 'init.d_stuff' modules; I'd want
an 'ldap' module that contained all of these resources.
Try thinking in terms of services; in the long run this will allow you
to get the most out of Puppet.
--Paul
Hi Paul,
first, thanks for your reply,
> On Mon, Nov 17, 2008 at 7:56 AM, Arnau Bria <arna...@pic.es> wrote:
[...]
> You must define dependencies at the "resource" level (though you can
> also define dependencies on defined types and classes; in this way you
> are using them as resources).
Yep, after reading a little more (puppet is really complex) I have
modified things and now I have dependencies between types.
All my modules are, now, "defines", and I have a big class where I call
my own definitions and there I set my dependencies.
define yaim {
pbs_client { "pic":
require => Local_users["pic_users"],
}
local_users { "pic_users":
require => Local_groups["pic_groups"],
}
local_groups { "pic_groups":
require => File["/opt/localconf/gLite3.1/yaim"],
}
[...]
> > If yes, may I call a resource defined in a module from another
> > diferntet?
>
> Resources are essentially global; you may refer to them from any
> module.
>
> I think you might want to take a step back and really think about how
> you want to make the best use of puppet. Make sure your modules
> represent logical chunks of configuration, rather than just grouping
> together all the resources that are similar. Why have a 'packages'
> module? If I were trying to configure an LDAP server, I wouldn't want
> to have the user in a 'system_users' module, the package(s) in
> 'packages' and the startup scripts in 'init.d_stuff' modules; I'd want
> an 'ldap' module that contained all of these resources.
>
> Try thinking in terms of services; in the long run this will allow you
> to get the most out of Puppet.
Thanks for your advice. I've modified things are now "modules" refer
to a complete services... but I come from quattor, and changing my
point of view is quiet hard...
> --Paul
Thanks,
Arnau
> Yep, after reading a little more (puppet is really complex) I have
> modified things and now I have dependencies between types.
> All my modules are, now, "defines", and I have a big class where I call
> my own definitions and there I set my dependencies.
>
> define yaim {
> pbs_client { "pic":
> require => Local_users["pic_users"],
> }
> local_users { "pic_users":
> require => Local_groups["pic_groups"],
> }
>
> local_groups { "pic_groups":
> require => File["/opt/localconf/gLite3.1/yaim"],
> }
> [...]
I don't think I've seen others write defines like this, but I guess it
works. I'd have made a yaim class instead. If it's meant to represent a
particular group of nodes, then I'd subclass a more generic node class
as needed:
class cae-host {
include timezone-central, ntp, ntpdate
include sudo, syslog-ng
...
}
class public-host inherits cae-host {
package { "nfs-common": ensure => latest }
include active-directory-member
...
}
class cluster-host inherits public-host {
include rsh-server
include fluent
include ganglia::client
...
}
class pe2650-host inherits cluster-host {
include gaussian
include openmpi
include autodocksuite
ganglia::config{
"pe2650":
cluster => "CAE 24-7 Compute Nodes",
mcast_ip => "239.2.11.73";
}
}
node ch226-1, ch226-2, ch226-3, ch226-4, ch226-5 {
include pe2650-host
}
--
Mike Renfro / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University
>
> On 11/19/2008 4:42 AM, Arnau Bria wrote:
>
> > Yep, after reading a little more (puppet is really complex) I have
> > modified things and now I have dependencies between types.
> > All my modules are, now, "defines", and I have a big class where I
> > call my own definitions and there I set my dependencies.
> >
> > define yaim {
> > pbs_client { "pic":
> > require => Local_users["pic_users"],
> > }
> > local_users { "pic_users":
> > require => Local_groups["pic_groups"],
> > }
> >
> > local_groups { "pic_groups":
> > require => File["/opt/localconf/gLite3.1/yaim"],
> > }
> > [...]
>
> I don't think I've seen others write defines like this, but I guess
> it works. I'd have made a yaim class instead. If it's meant to
> represent a particular group of nodes, then I'd subclass a more
> generic node class as needed:
yaim is a configuration tool. It set some gLite env add users, etc...
local_users are unix accounts, but they depend on yaim groups and unix
group aswell, so I'm just trying to say that local_groups must wait
until yaim files exits (and file will notify yaim exec, whihc
is not showed in my code), and local_user must wait for local_groups...
local_users and local_groups are classes with users and groups with
type "user".
Anyway, I've modified a bit all my schema, and now I have yaim class
wich add repos, install yaim soft, creates local user and configures
torque. Dependencies are correlty solved now.
Thanks for your reply.
Arnau