On Jun 6, 2010, at 2:53 AM, Douglas Garstang wrote: > We used to pass a bunch of settings back to our modules from > definitions on the node manifests. Since external nodes don't support > definitions, I presume these definitions have go get pushed back into > a module and a class somewhere, and then included in the external > node. You effectively then include the node's class (where the > definition are) in the external node. This seems completely > counter-intuitive to me, and I must have it wrong, so I was hoping to > see some real world examples.
I won't say there's a correct way to think about this, but I can tell you what makes sense to me (and apparently those designing Puppet's architecture). Don't think about what needs to happen to a node. Think about WHY it needs to happen. For instance, don't think “I need httpd on this machine”. Think “This machine is a web server” and “Web servers need to have httpd installed” as two separate things. This naturally puts all of your nodes into classes. Maybe you only have one such server now, but will you always? Do you want to recreate the entire configuration when a similar node becomes necessary? I’m not sure what you plan to use for external nodes, but I use LDAP where classes are the primary thing, but you can also set various ‘puppetVars’ on an individual node if you really need a one-off configuration. -- Rob McBroom <http://www.skurfer.com/> The magnitude of a problem does not affect its ownership. -- 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.
