On Mon, Dec 10, 2012 at 3:05 AM, swair shah <[email protected]> wrote: > > Here is what I'm doing right now: Instead of compiling catalog everytime > when a node sends a request to the master, check if the modules included for > that node are changed or not, if they are changed then only compile the > catalog. > > Q: How will I know which are the modules included in a node? A. a Puppetdb > query can give me a list of modules included in a node.
Unfortunately that information isn't in the catalog - the best you could do is infer which module a class should have come from based on the name. :( Worse, since PuppetDB uses the catalog it also doesn't have this information. > Now is there a clever way to track a module for changes and then make > decision about compiling catalog based on that? > > Also let me know if what I'm trying has been tried before or has some > loophole! The only problem I am aware if is that modules *can* have more inputs than you might expect: StoreConfigs, the `generate` function and friends, hiera, the automatic data bindings, and the ENC can also change the final catalog without the manifest itself having changed. If you control your environment and are willing to accept the limitation that those inputs changing doesn't trigger a new run, though, it should be fine. -- Daniel Pittman ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
