Re: [Puppet Users] Thoughts on roles/profiles class paradigm
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.
Re: [Puppet Users] Thoughts on roles/profiles class paradigm
On Jan 9, 2013, at 4:34 PM, Wolf Noble wno...@datapipe.com wrote: My colleagues and I are contemplating refactoring our modules to take advantage of the roles/profiles paradigm suggested by Craig Dunn in his blog post found here: http://www.craigdunn.org/2012/05/239/ Before we jump feet-first into adopting this paradigm, I thought it a good idea to reach out and see what everyone else thinks about this. This looks very similar to Jordan Sissel's pure fact-driven nodeless puppet design[1], something I'm looking to adopt for an upcoming project. The idea makes a lot of sense to me. [1]: http://www.semicomplete.com/blog/geekery/puppet-nodeless-configuration -- 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.
Re: [Puppet Users] Thoughts on roles/profiles class paradigm
On 09/01/2013 20:03, Roman Shaposhnik wrote: * A role contains business logic Could you give an example here? What else are roles, but a flat collection of profiles? Essentially yes, thats all they are and while I generally opt to make them classes you could do this from within an ENC instead. The implementation is not as important as the concept, so if you want to replace the roles function with groups of profiles in an ENC you'll still get the same benefits. One reason I keep roles in code is it allows me to be a bit more flexible. For example I can use inheritance to minimize duplication roles::appserver::foo roles::appserver::baretc inheriting from roles::appserver where I might have stuff like tomcat. 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 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.
[Puppet Users] Thoughts on roles/profiles class paradigm
Hi Gang, My colleagues and I are contemplating refactoring our modules to take advantage of the roles/profiles paradigm suggested by Craig Dunn in his blog post found here: http://www.craigdunn.org/2012/05/239/ Before we jump feet-first into adopting this paradigm, I thought it a good idea to reach out and see what everyone else thinks about this. We're currently struggling with some problems that this paradigm seems to solve quite nicely; but I'm not convinced it's the best abstraction / organization paradigm out there. If you've not read it, I think It's worth the few minutes it takes to read. Thanks Craig, for writing it. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. -- 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.
Re: [Puppet Users] Thoughts on roles/profiles class paradigm
The professional services team at Puppet Labs has been using that with customers, and many customers have been happy with what that affords you. You effectively create a series of abstraction layers so that more junior sysadmins can look at a 'Role' and quickly see what's on the node without wading through a bunch of code. This also allows more senior sysadmins to trace the code back down through 'Profiles' and ultimately to the modules themselves to track down errors. It's a good pattern that lets everybody in charge of managing nodes be able to benefit from Puppet without having to get their hands TOO dirty (if that makes sense). Adrien Thebo also posted a sysadmin advent post similar here -- http://sysadvent.blogspot.com/2012/12/day-13-configuration-management-as-legos.html Does this help? On Wed, Jan 9, 2013 at 1:34 PM, Wolf Noble wno...@datapipe.com wrote: Hi Gang, My colleagues and I are contemplating refactoring our modules to take advantage of the roles/profiles paradigm suggested by Craig Dunn in his blog post found here: http://www.craigdunn.org/2012/05/239/ Before we jump feet-first into adopting this paradigm, I thought it a good idea to reach out and see what everyone else thinks about this. We're currently struggling with some problems that this paradigm seems to solve quite nicely; but I'm not convinced it's the best abstraction / organization paradigm out there. If you've not read it, I think It's worth the few minutes it takes to read. Thanks Craig, for writing it. This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you. -- 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. -- Gary Larizza Professional Services Engineer -- 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.
Re: [Puppet Users] Thoughts on roles/profiles class paradigm
Hi! On Wed, Jan 9, 2013 at 1:34 PM, Wolf Noble wno...@datapipe.com wrote: Hi Gang, My colleagues and I are contemplating refactoring our modules to take advantage of the roles/profiles paradigm suggested by Craig Dunn in his blog post found here: http://www.craigdunn.org/2012/05/239/ 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. -- 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.
Re: [Puppet Users] Thoughts on roles/profiles class paradigm
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 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.
Re: [Puppet Users] Thoughts on roles/profiles class paradigm
On Wed, Jan 9, 2013 at 2:08 PM, Craig Dunn cr...@puppetlabs.com wrote: 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. So what's the advantage of managing roles explicitly in Puppet as opposed to managing them in an ENC of some kind? I get the re-usability point (you can swap out ENC, use node definitions, etc). Is that all? I have two modules called 'roles' and 'profiles', And as I mentioned I find profiles to be quite useful. Its the role concept that I'm not necessarily * A role contains business logic Could you give an example here? What else are roles, but a flat collection of profiles? Thanks, Roman. -- 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.
