On Jan 20, 4:34 pm, Cody <c.a.herri...@gmail.com> wrote: > On Jan 20, 6:39 am, jcbollinger <john.bollin...@stjude.org> wrote: > > > > > On Jan 20, 3:00 am, Dan Bode <d...@puppetlabs.com> wrote: > > > > * the big reason I keep on leaning on it is for package dependencies. > > > Often > > > something needs an additional package installed (and it is possible that > > > other modules may have that same package dependency, and I don't want to > > > have to create a new class every time that I need another package > > > (especially for something complicated that may have tons of package > > > dependencies) > > > You describe one of the core use cases for virtual resources. Instead > > of relying on the defined() function, you can > > 1) define virtual Package resources in some central place(s) for all > > the packages your nodes might want to manage, > > 2) include that class wherever needed, and > > 3) *realize* Packages as appropriate wherever you know you need > > certain ones. > > > That avoids parse-order issues, doesn't require you to keep multiple > > definitions of the same resource synchronized, and makes it easier to > > find specific Package definitions among your manifests. In some cases > > you might even be able to leverage collections with selection > > predicates to simplify and clarify your manifests. I don't see a > > single reason to prefer use of 'defined' for this case. > > Defining all somewhat common packages in a central location becomes > unrealistic when you no longer "control" the code that is in every > module you use. If you obtain five modules from the forge and they > all require a specific package and so all define that package your not > going to convince, nor is it a good design to require everyone to move > the package definitions from that collection of modules. They need to > function as a collection out of the box.
On the contrary, if that's what is required for modules to be interoperable, and module authors indeed want their modules to be interoperable, then I think it would be relatively easy to persuade most authors to do it. I can think of ways to make it work, and I'll write more on that in some other thread. Sticking to the subject at hand, however, there remains the issue that defined() does not adequately solve the shared resource problem anyway. If two modules both rely on the same resource then it is not safe for one to assume that the definition of that resource provided by the other meets all its needs. The 'defined' function can maybe ensure that the manifests compile, but it cannot ensure that the resulting configuration is correct. That makes it worse than useless for the purpose, as far as I'm concerned. John -- 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.
