On Thursday, September 18, 2014 4:36:16 AM UTC-5, Jonathan Gazeley wrote: > > On 17/09/14 17:29, Trevor Vaughan wrote: > > Ah, so looking at warranty.rb and then stdlib...puppet_vardir.rb, you > > may be missing this: > > > > begin > > require 'facter/util/puppet_settings' > > rescue LoadError => e > > # puppet apply does not add module lib directories to the $LOAD_PATH > > (See > > # #4248). It should (in the future) but for the time being we need to > be > > # defensive which is what this rescue block is doing. > > rb_file = File.join(File.dirname(__FILE__), 'util', > > 'puppet_settings.rb') > > load rb_file if File.exists?(rb_file) or raise e > > end > > > > Thanks. I added a similar block of code to load util/warranty.rb but it > didn't cure the situation. Something is different though. Running facter > by hand no longer complains, but my 15-minutely emails from MCollective > as it tries to cache facts are still being sent: > > Could not retrieve fact='warranty_start', resolution='<anonymous>': > undefined method `[]' for nil:NilClass > Could not retrieve fact='warranty_end', resolution='<anonymous>': > undefined method `[]' for nil:NilClass > Could not retrieve fact='warranty_end', resolution='<anonymous>': > undefined method `[]' for nil:NilClass > Could not retrieve fact='warranty_days_left', resolution='<anonymous>': > can't dup NilClass > >
That suggests to me that you have moved on to a different issue. Matching up the code (facter/warranty.rb and facter/util/warranty.rb) with the error messages you report, it seems likely that function Facter::Util::Warranty::get_data() is failing on you. That will cause both Facter::Util::Warranty::purchase_date() and the Facter::Util::Warranty::warranties() to return nil. The ::warranty_start, ::warranty_end, and ::warranty_days_left facts all depend on those two functions, assuming without testing that they never return nil, hence the observed errors. As to why get_data() may be failing, it looks like there are several possibilities: 1) The function relies on calling an HTTP API at Dell to retrieve data (lines 6-12 and 60-72). It may be that that API has been modified or removed, or that it no longer serves data for the particular machines in question. 2) The get_data() function relies on the ::serialnumber fact. I am uncertain how that fact is computed, but maybe something changed that affected its result. 3) The get_data() function uses a local cache to avoid calling the Dell API every time. If that cache has been corrupted but not altogether removed then perhaps get_data() would fail. In addition, the local caching also means that, depending on the cache timeout, the change that triggered the error might have happened some time before the error started appearing. > BTW #4248 is a very old bug, surely it's still not being hit? > > https://projects.puppetlabs.com/issues/4248 > > That's not your issue. It pertains to plugin classes on the master that are present only in their modules (i.e. they have not yet been plugin-synced to the master itself). Facts are the one plugin type to which that bug cannot apply. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c83389a6-bb71-42a3-a7cd-3ebf6abb4d40%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
