On Fri, 2009-08-07 at 22:42 +0200, Brice Figureau wrote: > On 7/08/09 22:37, Markus wrote: > >> I'd say if we have an integration test that has a capitalized node > >> name that can be found via a differently-cased search, then I'd > >> consider that sufficient proof that it works. > > > > It doesn't work. > > Which is an issue. Can you send the test?
I now think the test I was originally using was mocking/testing at the wrong level. Specifically, it was thwarting the loaded_code's munge_name method which is where Luke's concern about the hash being case sensitive is addressed. But I'm semi-stuck. Here's what I believe: 1. The error is coming from lib/puppet/parser/functions/include.rb and is triggered by the klasses array coming back from the call to compiler.evaluate_classes not containing all the vals (class names as strings) passed to it as its first argument. This test is a simple Array#include? with strings. 2. Inside Puppet::Parser::Compiler#evaluate_classes (lines 130ff in lib/puppet/parser/compiler.rb) this array is constructed by starting with an empty vanilla Array and iterating through the class names "<<"ing them into the result array if scope.find_hostclass returns a non-nil/false value when given the name. My first thought was that the only way a name would not be in the array would be if either 1) scope.find_hostclass returns nil or false or 2) something modifies the name in-place (e.g. with String#replace! or String#downcase!, etc.). But looking at the code more closely I believe that the second case can not in fact happen because the same string object (not "dup"ed or otherwise severed) is used throughout these two levels, so if it _were_ modified then it would still match for purposes of the Array#include? 3. Therefore the problem is in Puppet::Parser::Parser::find_hostname or code which it calls. 4. The behavior of this code sequence did change (see notes on original patch on this message chain) as it was renamed/refactored from fqfind. 5. The underlying hashing code (Puppet::Parser::LoadedCode) appears to be case insensitive (via Puppet::Parser::LoadedCode#munge_name). 6. Therefore I suspect that the problem was caused by the removal of downcaseing in the fgfind -> find_hostname transition, and thus would be fixed by the patch. However, that's where I'm stuck. My understanding of the system isn't yet to a point where I can craft a test that would increase my confidence beyond this point, or that would convince anyone who isn't convinced by the above. Specifically, the levels of indirection are tangled enough that any test I write would be relying so heavily on the foregoing analysis in determining where, what, and how to mock/stub (and thus assuming it rather than testing it) that it would prove nothing. I don't mind pursuing these sorts of things when it results in my learning something, but I'm adverse to diving down solipsistic rabbit wholes for the hell of it. Thoughts, advice, or pointers on how to proceed, anyone? -- Markus --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
