Issue #5318 has been updated by Daniel Pittman.
The root cause of this problem is actually that the puppet master uses a current cache of the environment, which includes the data parsed from the manifests, but fails to update and manage that cache effectively. Specifically, we flush that cache after the compile of a catalog is complete, but before we serialize it and send it to the client. This was done to satisfy the precondition of the compile function, that it would refresh the available type data for the compile. Which, indeed, is a weak way to ensure that this precondition was satisfied. I suspect that it was also constructed this way because it would result (theoretically) in the environment being parsed at the start of compile, but would then stay consistent until the next compile run; it would try and avoid an update to a file in the middle of a compile run resulting in an incoherent set of definitions. (Note: it would absolutely not close the race, just reduce it in scope by only doing this once.) When we changed to putting more data in the catalog, to reduce the need for type and provider code on the client during catalog manipulation, we actually started using the known_resource_types from the environment while we serialized the catalog to send to the client. This happened *after* the cache flush, and resulted in the cache being renewed with a new environment (and a second parse of the files) during serialization. This, in turn, led to the precondition no longer being satisfied (although no one noticed because it was never documented or asserted as a precondition of compile). We would now parse changes from manifests only when we serialized the catalog, not when we started to compile – and the previous set of changes would leak over. Which, in turn, resulted in our taking two passes to notice the change; our sequence was that we would use the previous cache to compile, flush it, reparse in the serialization pass, then next time around would have the right input. Without looking at exact and correlated agent/master traces this looked to be doing the right things in the right places. ---------------------------------------- Bug #5318: puppet master behind passenger does not re-parse manifests correctly when running with default environment. https://projects.puppetlabs.com/issues/5318 Author: Dan Bode Status: Accepted Priority: Urgent Assignee: Category: compiler Target version: 2.6.x Affected Puppet version: Keywords: Branch: When running puppet behind passenger <ul> <li>apache - 2.2.3 <li>puppet 2.6.3 <li>rack 1.1.0 <li>passenger - 2.2.11 <li>centos 5.4 <li>ruby 1.8.5 </ul> <b>site.pp</b> <pre> node default { file { '/tmp/two/three': content => 'blah', mode => '661', } } </pre> when I change the mode of the file resource, I have to run the client twice for it to detect the change. after changing the manifest, do the dishes, run pupppet: <pre> puppetd -t info: Loading facts in certname info: Loading facts in certname info: Caching catalog for puppetclient info: Applying configuration version '1289885403' notice: Finished catalog run in 0.20 seconds [root@puppetmaster templates]# puppetd -t info: Loading facts in certname info: Loading facts in certname info: Caching catalog for puppetclient info: Applying configuration version '1289886035' notice: /Stage[main]//Node[default]/File[/tmp/two/three]/mode: mode changed '664' to '661' notice: Finished catalog run in 0.20 seconds </pre> I could not reproduce with edp. If I turn off apache and turn the puppetmaster service on (webbrick), this issue goes away. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
