Issue #18282 has been updated by Paul Lathrop.
Ugh. apparently I can't fix my messed-up description. Sorry. ---------------------------------------- Bug #18282: Top-level includes cross catalogs during concurrent catalog compilation. https://projects.puppetlabs.com/issues/18282#change-79583 Author: Paul Lathrop Status: Unreviewed Priority: Normal Assignee: eric sorenson Category: compiler Target version: Affected Puppet version: 2.6.14 Keywords: Branch: For some time we've been seeing some nodes getting incorrect classes applied by puppet. It has taken time to track this down, but it appears to be a bad combination of us doing something bone-headed and an actual concurrency issue in the puppet master. While testing our manifests for an upgrade to 2.7, I was able to consistently cause the incorrect application of a class to a node by running a single puppet master process and two clients - the second client connecting and requesting a catalog while the first client's catalog was still compiling. This would cause the incorrect class to be applied to one of the nodes. While helping me track this problem down, Eric Sorenson asked if we had any top-level includes. It turned out that we did; at one point we ran into problems doing this: <pre> define foo ( $bar = $other_class::bar ) { </pre> i.e. defaulting the value of a define parameter to a variable in another scope. So we started doing this: <pre> include other_class define foo ( $bar = $other_class::bar ) { </pr> At this point I'm not sure why the original code didn't work - it appears to function now. However, our code was littered with these top-level includes. It was still confusing why the incorrect class (which was being included in the top scope) wasn't applied to everything, but we reasoned that this is because the autoloader doesn't load the .pp unless a node uses that define. So, if you have top-level includes, and you have concurrent clients requesting catalog compilation, there is a concurrency bug which causes code loaded by one catalog compilation to end up affecting the other catalog's compilation. Although a very fair response to this is "don't do that" I do believe there's still a bug here due to the fact that the catalog compilations are not isolated from one another. I've reproduced this on 2.6.14, 2.7.20, and 3.0.2 Assigning to Eric for his comments. -- 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.
