On Nov 29, 6:15 pm, Lars Francke <lars.fran...@gmail.com> wrote:
> This is the part I don't understand. The more verbose I've been the > more errors I got because of duplicate definitions etc. Which only > supports the point that I still don't "get" the Puppet model :) Wrapping up a bunch of things in a define may reduce the number of error *messages* simply because the error shifts from the usages of a bunch of separate resources to the usage of one define. That doesn't change the nature of the the error. One of the things that sometimes gives Puppet newbies trouble is that it employs a declarative model rather than an imperative one. In other words, it's an expert system, not a scripting language. The Puppet language is all about describing the state that your system should have, and Puppet later uses that description to ensure that your system is in that state. This is very powerful and flexible, but sometimes confusing, too. It is the core reason why you cannot declare duplicate resources. Perhaps it would help to start by writing your manifests without using any definitions and without using any variables other than facts, at least for these directories you are managing. This will require that every directory and file you are explicitly managing must be named in some (exactly one) File resource. Use recurse => true for directories where it is appropriate to do so (i.e. you don't necessarilly need to explicitly manage every single file). By all means, do organize these resources into classes in a manner that makes sense to you. The objective there is to create a set of manifests that get the job done, and which you can then use, if you wish, as a basis for further development. When every file you are directly managing is explicitly named, it should be easy to ensure that there are no duplicates. By classifying the resources in that form, it should be trivial to ensure that you have no overlapping classes. And if you later refine those initial manifests to shorten them by re-introducing variables and definitions, then it should be clearer what variables you want and what definitions would be useful. For what it's worth, I think it's a good idea in general to hold Puppet definitions in reserve for places where you really need them or where they provide a big win. Good Luck, 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-us...@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.
