> However, there are a few technical hurdles we need to cross before we > can do it in the core. In particular, we need to resolve all > relationships before we trim the catalog in this way - e.g., someone > can currently depend on one of those wrapping definitions, and if you > just remove that wrapper, the dependency will fail.
Yes. Actually, what I meant with "flatten the catalog" would be to pass the dependencies from the definition down to the "real" resources. As far as I understood the dependencies in puppet this would be equal to have the dependencies on the wrapping define, right? > One of our goals is to get to the point where the dependencies are > all resolved on the server anyway, and this could be a good driver to > get that done. I also want to make it easier to have things like > post-compile filters on the server for this kind of work, but it's > not all that challenging at this point - at worst, you could do > something like create a 'compile_trim' terminus that uses the > existing compiler terminus but trims the results in the way you're > mentioning, and then start puppetmasterd with > --catalog_terminus=compiler_trim. > > Does that make sense? Is it worth your experimenting with that? Yep, makes sense. Whether I will start experimenting with your suggestion depends a bit on the requirements I will get to further optimize things. Unfortunately, I'm currently quite occupied with the daily business, which reduces my time for experiments. However, I thought it might be worth to share my ideas and also to open the mentioned feature request, so at least it is documented. Thanks for your answer! ~pete -- 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.
