On Thu, May 31, 2012 at 4:39 PM, Wil Cooley <wilcoo...@gmail.com> wrote:
> I'm probably trying to solve a problem that I don't really need to > solve, but I'm hard-headed enough that I'm going ahead anyway... > > I am using foo::params to centralize things like file paths, package > names, etc. that vary by $::osfamily, but I am running into > difficulties where the actual parameters might vary partly on > $::osfamily but within an OS family there might be other variations > not represented by facts. > > Let's say I have a platform like Solaris where a particular software > package may be provided by several different parties and where I might > have perverse reasons for wanting to vary the package source-provider > on a system-by-system basis. Take Apache, for example: on one host > that's doing simple static file serving, I might use the 2.0 build > that is included with Solaris--minimizes dependencies, patches come > from OS vendor, etc.; on another Solaris box, a developer wants > something more complicated, so the 2.2 build from OpenCSW is needed. > And another developer wants Apache from Sunfreeware. > ... Or CoolStack or WebStack ... oh, Solaris... If stupid internal politics do not seem like an adequate > justification, let's say I'm building a module that I intend to > distribute via Puppet Forge, where I shouldn't just assume that > everyone will want his package from one vendor or the other. > > How do you solve this? > Honestly, these feel like different modules to me primarily because they're very different things on Solaris. Some of those apaches may have SMF manifests, some may not, the paths are going to vary wildly, etc.. I think doing all of this in one module will make the module overly complex. The majority of the code will be dealing with "What Apache instance am I really managing here?" Unless you use defined resources, it will also be difficult to manage multiple copies of Apache on the same node with this module. If you can get it down to variations of the source and provider parmeters of one or more package resources then you can probably get away with a single module, but even then I'd recommend multiple classes to make things clear and easier to understand. -Jeff -- 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.
