I was in a position to build a puppet environment from scratch. After lots of studying and trying different suggestions the profile/role paradigm is proving flexible enough to meet any challenge we have faced thus far. We apply a role to nodes that should be identical (typically clusters of nodes) and the same role gets applied to dev/test/prod clusters. This solved two problems. 1) It works nicely for integrating with the release process where clusters are tested as a platform. We can make changes to applications, middleware and the OS in the role. Dashboard reports then show what will change on dev/test/prod. The changes are then applied following the schedule of the release process. 2) Applying only roles to nodes keeps the dashboard clean if using it as an ENC. The only classes found on the dashboard are roles. No one has to guess what a server is used for because the single applied role to the cluster makes it obvious. In all honesty though we do apply roles to node groups. So if a node finds itself in multiple groups it will have multiple roles. But the roles are always mutually exclusive or the underlying classes are written to handle the potential for resource conflicts.
The final big advantage I see is having terminology and a proven pattern to communicate ideas between team members. Once we settled on the profile/role pattern we quit going in circles on how to implement and solutions to perceived problems became clear and in some cases solved themselves. All and all very satisfied with the pattern so far. Those are my thoughts. Hope they are helpful. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/jEyW_0N7YxEJ. 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.
