Puppet users - Jan 2009 - Mounts: virtual ressources or multiple classes ?

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 ?

Thanks !
--~--~---------~--~----~------------~-------~--~----~
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 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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On 29 jan, 21:56, Luke Kanies <l...@madstop.com>
wrote:
> I''d say the answer depends on how often you have consistent
groupings.
It''s more about inconsistencies :-)
> 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.
Well, actually things are even worse than I thought. I''m new to the
system we''re trying to "puppetize":  lots of mounts all over
the place
(NFS-happy people over here).

So first I''m going to find map what is needed where with what options
(RO/RW...). Bit of a nightmare but highly needed. :-/
> 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.
Yep, you''re right.
> 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.
Will dig into this too.

Thanks for your input !

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