On Jan 27, 2009, at 4:58 AM, Calimero wrote:
>
> Hi,
>
> We're trying to implement the following structure:
>
> class my_pool {
> include linux, httpd... base modules
>
> include project_A
> include project_B
> }
>
> One pool can have many projects. One projects can be on many pools.
>
> A project is basically made of:
> - directories + NFS mounts
> - users and crontabs
> - apache virtualhosts
>
> Problem is that users and mounts can be used by differents projects
> (yet they need not be setup on all nodes/hosts). So I can't have this:
>
> class project_A
> {
> user { "bob" :
> ...
> }
>
> # also needed in project_B
> file { "/mnt/used_in_several_projects":
> ....
> }
>
> mount { "/mnt/used_in_several_projects" :
> ....
> }
> }
>
> I see two options:
> - have virtual mounts/users/files in mounts::virtual and
> users::virtual classes and then realize() them where needed
> - create various classes which include real (non-virtual) ressources
> and then include the various classes where needed.
>
> I'm not sure what way I should go. Having a mounts::virtual class with
> all (potentially) common mounts means I don't have to split mounts
> among various classes which may end up quite messy over time. I just
> throw mounts that intersect two or more projects in the virtual class
> and realize() where needed.
>
> On the other hand, having all the realize() function calls in each
> project class somewhat defeats the purpose of
> "reusability"/"factorization"...
>
> Anyway, what would you suggest on the long term ?
I'd say the answer depends on how often you have consistent groupings.
If the list of mounts that a given service or host uses is relatively
arbitrary, then there's no real way to get away from the 'realize'
calls.
On the other hand, if the mounts tend to follow natural groupings,
then you could create a few sets of classes with the realize() calls
in them.
Either way there is at least somewhat of a win because your
configuration data is normalized: You only have mount details (other
than name) in one place in your configuration, for a given mount entry.
There is a third way, though; this won't work for all situations, but
you could tag your mounts with various metadata, and then use a query
to pull down mounts tagged a certain way. E.g., here's my simple test
that demonstrated this works:
@notify { "It worked!": tag => [yay, ness] }
Notify <| tag == yay |>
This allows you to build arbitrary metadata around your resources, and
then add them to the catalog without literal listings.
--
The only thing that saves us from the bureaucracy is inefficiency. An
efficient bureaucracy is the greatest threat to liberty.
--Eugene McCarthy
---------------------------------------------------------------------
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
