(PCP-306) Use last_run_report mtime to check for updates #416
Conversation
|
/cc @nicklewis The only case where I see this getting us into trouble is if the environment undergoes some sort of rollback or someone manually copies an old report into place after a run. Both of those seem unlikely. Update: ok, I can think of another case. Updating time could result in the new catalog being written with an identical mtime. This seems unlikely, as time is measured in microseconds, and will only result in an unknown status. However it could be improved by checking checksum, which should be unique because transaction_uuid will change with each run. Could also compare transaction_uuid or time from the report, but that seems potentially more expensive and error prone (parsing JSON). |
|
AppVeyor won't pass until #414 is merged. |
|
AppVeyor is happy after #414 fix. Pinging @nicklewis. |
Update links to point to version 1.0. The pcp-specifications repo was reorganized to separate different versions of the specification.
Previously last_run_report would be assumed to use a newer time stamp if the triggered Puppet run successfully updated the report. NTP updates during the Puppet run could potentially violate that assumption. Switch to checking mtime on the report, and assuming if mtime has changed that a new report was written.
|
Also, pinging @mruzicka. |
|
This approach makes sense to me. |
|
Will merge as soon as puppet-agent CI is back to green. |
Previously last_run_report would be assumed to use a newer time stamp if
the triggered Puppet run successfully updated the report. NTP updates
during the Puppet run could potentially violate that assumption. Switch
to checking mtime on the report, and assuming if mtime has changed that
a new report was written.