Great to see this discussed, thanks for bringing it up. (Disclaimer: I'm the author of the blog post)
On 03/06/11 18:05, Luke Bigum wrote: > On 03/06/11 16:21, Douglas Garstang wrote: >> I'd also like to see something, maybe in the best practices document >> on the Puppet Labs website indicating which is the correct way to >> handle specific operating ystem logic. Having multiple classes (ie a >> lot of classes) per module, means more files, which in my opinion, >> makes things confusing and it's never really clear which is the best >> way to break things up. When you have more than a few files, there's >> also a tendency to create subdirectories under manifests/, and have >> stuff like module::A::B.pp.... and when you start doing that, it >> becomes even more unclear how things should be arranged. I tend to use a single init.pp still for a lot of things, as I find myself writing a fair amount of common code even across different platforms. I don't find it particularly useful to split it into a new file for common bits, another for Red Hat and another for Solaris. It becomes difficult to manage as dependencies are spread across files and opportunities to rationalise common code are missed. Where I have modules where the OSes have nothing in common then I would split them out into separate redhat.pp and solaris.pp manifests. For me, this is a very small number, but it'll naturally depend on your environment. > I guess it's up to the site and the Puppet admins on how to break up > their classes. I'm not sure there's an all encompassing best practice as > everyone's requirements will be different. For example if I was just > managing CentOS and Red Hat systems, I might simply embed if/else logic > in a single class and handle the differences in the OS there, as they > are mostly the same and splitting off a separate class might be a waste > of time. > > If I was managing a site with Fedora, Ubuntu, Macs, etc, I'd definitely > go down the "conditionally include classes and subclasses", mainly for > management reasons, like a typo in "class somefile::ubuntu" doesn't > affect "class somefile::redhat". Also the logging of resources indicates > exactly which class::subclass::subsubclass a resource is declared in, so > I know where to go hunting to make a change to it. In practice I'd make > judgement calls about when to split a class into subclasses based on > operating systems or to nest if/else statements in a class based on how > complex the class was getting, and so I'd have a mixture of both. That's fair enough. I found the consistency quite useful when working in a team, so it became a familiar pattern across every module in this case - even if that meant some classes were empty. -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- 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.
