Issue #18282 has been updated by Andrew Parker. Status changed from Investigating to Needs More Information Assignee changed from Andrew Parker to Paul Lathrop
Eric, I think you might be right that this is related to #4211. I took a look at <https://github.com/puppetlabs/puppet/blob/master/lib/puppet/parser/type_loader.rb#L115>, which looks like there might be a race for determining what is loaded. I think it can end up with one thread thinking that a particular type exists and the other thinking it doesn't exist. I'm not 100% certain about that though. Paul, can you describe the exact setup you have? What ruby version is this on? How you are running the master? Are both agents requesting a catalog for the same node? In the same environment? What is the difference that the two agents see (e.i. are resources missing from one of the catalogs?)? ---------------------------------------- Bug #18282: Top-level includes cross catalogs during concurrent catalog compilation. https://projects.puppetlabs.com/issues/18282#change-79729 Author: Paul Lathrop Status: Needs More Information Priority: Normal Assignee: Paul Lathrop 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 ) { </pre> 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.
