Jira (PDB-1266) All report hashes need to be recomputed during 3.0.0 upgrade

Ryan Senior (JIRA)

unread,

Feb 25, 2015, 10:18:41 AM2/25/15

to puppe...@googlegroups.com

Ryan Senior created an issue

PuppetDB /

PDB-1266

All report hashes need to be recomputed during 3.0.0 upgrade

Issue Type:	New Feature
Assignee:	Unassigned
Created:	2015/02/25 7:18 AM
Fix Versions:	PDB 3.0.0
Priority:	Normal
Reporter:	Ryan Senior

Previously we were not normalizing timestamps as the data came into PuppetDB. This meant that potentially the same date could hash to different values based on how the date was represented in string form. Ticket

~~PDB-1241~~ fixed that, but will cause existing reports to now hash differently. Before we release 3.0.0 we're going to have to go fix up the existing reports.

Add Comment

This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a)

Ryan Senior (JIRA)

unread,

Feb 25, 2015, 10:22:47 AM2/25/15

to puppe...@googlegroups.com

Ryan Senior updated an issue

PuppetDB /

PDB-1266

All report hashes need to be recomputed during 3.0.0 upgrade

Change By:	Ryan Senior
Story Points:	2 3

Add Comment

Ryan Senior (JIRA)

unread,

Feb 25, 2015, 10:44:28 AM2/25/15

to puppe...@googlegroups.com

Ryan Senior updated an issue

PuppetDB /

PDB-1266

All report hashes need to be recomputed during 3.0.0 upgrade

Change By:	Ryan Senior
Sprint:	PuppetDB 2015-03- 11 25

Add Comment

Wyatt Alt (JIRA)

unread,

Feb 27, 2015, 5:14:41 PM2/27/15

to puppe...@googlegroups.com

Wyatt Alt commented on

PDB-1266

Re: All report hashes need to be recomputed during 3.0.0 upgrade

In the non-HA case I can't see this being an issue, since the only requirement we place on report hashes is that they be unique. We don't use them for diffing like factsets and catalogs.

In the HA case the concern is that pre-existing PuppetDB A syncs to new PuppetDB B, and the two end up with identical reports that are hashed differently.

I think we may have the same issue with factsets (now that timestamps have been removed from the hash) and catalogs (now that we use certname instead of name). These are more transient because we don't store historical data, but could cause confusion during upgrade.