Bug #3149
closed
Facter 1.7.3 upgrade breaks fact timestamps in Foreman 1.2.2
Description
Upgraded to facter-1.7.3-1ubuntu1 and Foreman stopped reporting the timestamp on facts that it received from my ENC script.
The timestamp in the YAML file for the node has changed its definition from:
!ruby/sym "_timestamp"
to just:
"_timestamp"
Thanks to ohadlevy on IRC I was able to correct this in my install by changing the following file:
/usr/share/foreman/app/models/host/base.rb
Line 67 now reads:
time = facts[:_timestamp] || facts['_timestamp']
This should support both the old and new way of defining _timestamp in the fact file. I can confirm this fixes the issue for me, and can submit a patch tomorrow for this if needed.
Thanks!
Updated by Dominic Cleal about 11 years ago
Thanks for the report. Foreman 1.3.0 changes the facts upload somewhat, as we stop loading the YAML file as-is, and upload it as JSON through the proper Foreman API. I think this means that the symbol/string difference you're seeing in the timestamp here might be squashed away as it passes through the API.
Greg, can you confirm please? Or if you're able to test the 1.3 release candidate Ben, that'd be great too.
Updated by Greg Sutcliffe about 11 years ago
I wonder if we should just make sure the facts hash is a HashWithIndifferentAccess? That would make sure we don't run into issues like this again in the future. Dominic, is this worth getting to 1.3? I think it is.
Updated by Greg Sutcliffe about 11 years ago
Btw, this is still an issue in 1.3, as the affected code is internal to Host::Base, after we converted the incoming data to a hash.
Updated by Greg Sutcliffe about 11 years ago
- Status changed from New to Need more information
I take it back, the API already creates it as a ActiveSupport::HashWithIndifferentAccess and both forms of access to _timestamp work. I think this is not a bug for 1.3 - Ben, any chance you can confirm using the 1.3rc2 candidate?
Updated by Ben McClure about 11 years ago
This report was regarding my production foreman/puppet server and I was planning to wait until 1.3 was out of RC to upgrade it there, however I could probably clone this system and spend a little time testing in a dev environment with 1.3rc2 to confirm.
Updated by Greg Sutcliffe about 11 years ago
That would be great if you have the time, although I'm fairly sure it'll be fixed in the 1.3 release, based on my tests today.
Updated by Dominic Cleal about 11 years ago
- Status changed from Need more information to Resolved
Marking as resolved, please re-open if you see it on 1.3.
Updated by Dominic Cleal about 11 years ago
- Status changed from Resolved to New
- Target version set to 1.2.3
By request, I'm re-opening this in case we can make a 1.2.3 release with the proposed fix. Not sure if/when we will yet. If this issue affects you, please add a comment and vote up so we can keep track of demand.
Updated by Dominic Cleal about 11 years ago
- Status changed from New to Resolved
- Target version changed from 1.2.3 to 1.3.0
Cancel that, I didn't realise that fact uploads still happen and it's just the timestamp affected, so the severity's low.
Updated by Anonymous about 11 years ago
This hit me today after the puppet master got upgraded from 3.2.4 to 3.3.1.
No facter or puppet clients version changes were involved.
The mentioned fix in the description fixed it also for me.
The relevant communication on IRC:
<mmoll> in /var/lib/puppet/yaml/facts/<hostname>.yaml: "_timestamp": 2013-10-08 20:17:26.476881 +02:00
<Dominic> ah, so it's that bug - maybe the facter update was a red herring and it's just Puppet
<Dominic> makes more sense for the timestamp to come from the master than the agent's facter, so yes
<ohadlevy> Dominic: yeah, certname, timestamp etc comes from the master