Hello Craig,
I was wondering if someone could please help or explain the best approach to setting up puppet as our first requirement is to support multi-tenant within our company what I mean by this is we have different teams supporting different O/S or the same O/S but different configurations, and will probably call the same modules but can't touch the others configurations etc Team A - Windows O/S Config A Team B - Linux O/S Config B Department C - Windows O/S Configs C & D >From what I've been reading there seems multiple ways of doing this, some are being phased out, and some are aren't that clear. The easiest option would be to add different manifests for different groups / teams within site.pp, but if I make changes to the sub-manifests, i'd need to "touch" the site.pp file for changes to kick in, which could also effect the other teams / group changes and cause outages ? Can some please recommend the best approach to multi-tenant Regards James On Wednesday, 9 January 2013 22:08:19 UTC, Craig Dunn wrote: > > On 09/01/2013 13:56, Roman Shaposhnik wrote: > > I think I've seen this one before and got curious about it as well. It > > seems that Craig is advocating 1-1 mapping between nodes and roles and > > that makes me think of the 'roles' as a sort of poor man's ENC. As > > such, I'd be very curious to hear what kind of issues do you think it > > will help you solve. Now, having 'profiles' as the place to handle > > inter-module dependencies seems like a pretty good idea. Thanks, Roman. > > The point was not a 1-1 mapping between nodes and roles (although that > was mentioned), the key point I was trying to make is to add layers of > classes to provide abstraction between your node definition (whether > thats in an ENC or site.pp) and the components that get pulled in. > > If my post is tl;dr I'll summarise it with; > > I have two modules called 'roles' and 'profiles', and other modules > we'll just refer to as 'component modules' and nodes have role classes > applied to them, which include profiles, which include component modules > > * A role contains business logic > * A profile defines the logical software stack that defines what > components are needed > * The component modules are the building blocks that manage resources > (eg: ssh, mysql, apache...) > > Theres probably a few ways of achieving the same thing - but they key > here is abstracting the components from the nodes. > > Craig > > > -- > Craig Dunn > Professional Services > Puppet Labs Inc. > http://www.puppetlabs.com > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
