Puppet users - Mar 2008 - Trying to configure Bacula with Puppet (exported resources and N to N relationships)

Hi there,

I''ve got a problem modeling Bacula configuration files, I
don''t know
if I''m too thick today, or it can''t be easily done using
puppet:
Bacula has a Director, a Storage Daemon and Devices (Director and
Storage Daemons may be located in different machines). A Director may
connect to several Storage Daemons, a Storage Daemon may be accessed
by several Directors (n to n), and a Storage Daemon may have several
Devices attached (1 to n). Access is controlled by shared passwords
between Director and Storage Daemon, so if a Director can access a
Device in a Storage Daemon, it may access any Device in that Storage
Daemon.

So for each Director/SD/Device combination I must create:

1. A SD/Device definition in the Director''s configuration file (one
per SD/Device pair being used, including the shared password),
2. A Director definition in the SD''s configuration file (only one per
Director, including the shared password),
3. A Device definition in the SD''s configuration file.

I was trying to solve it using definitions and exported resources, but
the n to n relationship is killing me... I have thought of the
following approaches:

1. Create a definition bacula::storage::device. This definition takes
an array of directors that may access it as a parameter. The main
problem with this approach is that I cannot handle the array of
directors in puppet itself, so I can''t export a different resource for
each director in the array. Anyway, if I''d be able to export such a
resource, it would be duplicated in several devices (same director
being able to access several devices)
2. Create two definitions: bacula::storage::device and
bacula::storage::director. This would let me modify the storage
daemon''s configuration file, but I can''t see an easy way to
create
exported resources for every device defined in a storage daemon: for
every director I should obtain a list of devices defined in the
storage daemon and export a resource to modify the director''s
configuration file.
3. Create three definitions: bacula::storage::device,
bacula::storage::director, and bacula::director::device. First and
second definitions would modify the storage daemon''s configuration
file, and third one would modify the director''s configuration file.
With this approach I wouldn''t export any resources, but everything
would be disconnected, and I could easily create inconsistent or wrong
configurations.

Am I missing anything?

Thanks in advance, best regards
Jose
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 18 March 2008, José González Gómez wrote:
> Hi there,
>
> I''ve got a problem modeling Bacula configuration files, I
don''t know
> if I''m too thick today, or it can''t be easily done using
puppet:
> Bacula has a Director, a Storage Daemon and Devices (Director and
> Storage Daemons may be located in different machines). A Director may
> connect to several Storage Daemons, a Storage Daemon may be accessed
> by several Directors (n to n), and a Storage Daemon may have several
> Devices attached (1 to n). Access is controlled by shared passwords
> between Director and Storage Daemon, so if a Director can access a
> Device in a Storage Daemon, it may access any Device in that Storage
> Daemon.
>
> So for each Director/SD/Device combination I must create:
>
> 1. A SD/Device definition in the Director''s configuration file
(one
> per SD/Device pair being used, including the shared password),
> 2. A Director definition in the SD''s configuration file (only one
per
> Director, including the shared password),
> 3. A Device definition in the SD''s configuration file.
>
> I was trying to solve it using definitions and exported resources, but
> the n to n relationship is killing me... I have thought of the
> following approaches:
>
> 1. Create a definition bacula::storage::device. This definition takes
> an array of directors that may access it as a parameter. The main
> problem with this approach is that I cannot handle the array of
> directors in puppet itself, so I can''t export a different resource
for
> each director in the array. Anyway, if I''d be able to export such
a
> resource, it would be duplicated in several devices (same director
> being able to access several devices)
> 2. Create two definitions: bacula::storage::device and
> bacula::storage::director. This would let me modify the storage
> daemon''s configuration file, but I can''t see an easy way
to create
> exported resources for every device defined in a storage daemon: for
> every director I should obtain a list of devices defined in the
> storage daemon and export a resource to modify the director''s
> configuration file.
> 3. Create three definitions: bacula::storage::device,
> bacula::storage::director, and bacula::director::device. First and
> second definitions would modify the storage daemon''s configuration
> file, and third one would modify the director''s configuration
file.
> With this approach I wouldn''t export any resources, but everything
> would be disconnected, and I could easily create inconsistent or wrong
> configurations.
>
> Am I missing anything?

You can collect resources by tag. See e.g. my munin module, which uses this to 
distribute file snippets only to the central munin collector.

Perhaps you can use this to create exports for specific hosts, like tagging 
with destination fqdn or something.



Regards, DavidS

- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH5SNn/Pp1N6Uzh0URAl0GAJ9W+vp2cjLXeFFain4zC2R30XeaogCaAk1q
ac1fXbdxatb6+W0RZVaAkdE=F1hy
-----END PGP SIGNATURE-----

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