On Thursday, July 18, 2019 at 7:59:26 PM UTC-5, Lesley Kimmel wrote: > > Hi all; > I'm a Linux engineer who went through a typical growth period with Puppet > and finally landed on the Roles and Profiles pattern which generally works > well. > > I have a coworker that started on after me and doesn't like this pattern > and having to update profiles or base modules when new functionality is > needed; especially for quick one-off things. > > So he's basically started creating one class containing 'create_resource' > declarations for the standard Puppet resource types (file, user, group, > exec, etc.). Then he just adds all of the appropriate parameters in hashes > in Hiera. He's convinced this is the right way to do it since he hasn't yet > ran into a scenario where this doesn't work easily. >
All technical considerations notwithstanding, this is a problem that should be addressed by your manager or group leader. I estimate chances of logic-ing your junior colleague into doing things differently to be low, no matter what argument you present. They don't have the experience or vision to inform a different opinion than they have formed, and they are focused on expediency. But there is enormous benefit to taking a consistent approach within the team. The manager / leader should recognize that, and it is reasonable to hope that the junior member will at least accept that, even if they don't like the extra steps they need to take to be consistent. Of course, *management* might want reasons for continuing with the roles & profiles approach instead of switching to what amounts to pure-Hiera manifests. The problem with this is that it is hard to give concrete examples before you run into actual issues, and you would prefer to avoid such issues in the first place. IT-savvy managers might be influenced by the observation that preferring Roles & Profiles over all-Hiera can be characterized as favoring composition over inheritance for customizing and deriving machine configurations. They might also appreciate that encapsulating units of configuration in Puppet classes constitutes a modular approach that is easier to manage and maintain in the aggregate, over time. Your coworker's approach is reasonable for emergency fixes that need to roll out absolutely as fast as possible, but if you build your infrastructure management as a tower of such jerry-rigs then down the road you are probably facing increasingly difficult maintenance problems and ultimately a large-scale rewrite / refactoring. > I told him if it was the right way then all the smart people working with > and developing Puppet would have put it out as the best practice. However, > I can't seem to come up with a really great scenario that will convince > him. Can anyone share thoughts on scenarios where this patter will blow up > [hard]? > It's going to become more and more prone to duplicate resource declaration errors as the number of resources declared this way grows. It's going to require either an increasingly deep and complex Hiera hierarchy, or else a great deal of per-individual-node configuration data. There is every reason to expect a lot of data duplication to emerge in such a situation. Note, however, that you don't necessarily need to go all the way to roles and profiles to address most of those considerations. Many of them can be addressed to a significant extent simply by thoughtful design of your main classes and modules. Overall, it's a question of scope. The problems addressed by Roles & Profiles are fairly high-level ones of organizing and maintaining a large and diverse manifest set for infrastructure that itself has a lot of diversity. For simple situations it is probably a bit overkill, but well-designed classes and modules are still much to your benefit. John -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4ed06e35-b8cb-4c81-99a4-7f89955f58dc%40googlegroups.com.
