Bug 984130 - Updating content with an identical package file that had been previously deployed for a resource results in package history being replaced with the latest version info/creation timestamp
Updating content with an identical package file that had been previously depl...
Status: CLOSED NOTABUG
Product: JBoss Operations Network
Classification: JBoss
Component: Content (Show other bugs)
JON 3.1.2
Unspecified Unspecified
medium Severity high
: ---
: JON 3.2.1
Assigned To: Stefan Negrea
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-12 18:31 EDT by Larry O'Leary
Modified: 2014-02-13 09:14 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-13 09:14:45 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Content History page when initial version is discovered (1.0) (71.25 KB, image/png)
2013-07-12 18:31 EDT, Larry O'Leary
no flags Details
Content History page when same file is uploaded by as version is 1.1 (94.88 KB, image/png)
2013-07-12 18:33 EDT, Larry O'Leary
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 423903 None None None Never

  None (edit)
Description Larry O'Leary 2013-07-12 18:31:49 EDT
Created attachment 772903 [details]
Content History page when initial version is discovered (1.0)

Description of problem:
If content has been deployed and then updated with an identical package file, the result is the history for the existing package file is replaced with the latest info.

For example, if you deployed package version 1, then 2, then 3 and then you took the exact package file (same file checksum/hash) that was used for version 1 and updated the content and claimed it to be version 4. The package history would reflect 4, 2, 3, 4 instead of 1, 2, 3, 4. 

Version-Release number of selected component (if applicable):
4.4.0.JON312GA

How reproducible:
Always

Steps to Reproduce:
1.  Start EAP 6 domain server.
2.  Start JON system
3.  Import EAP 6 domain controller into inventory
4.  Configure EAP 6 resource's management user/password
5.  Verify that resource is UP and its managed servers have been discovered.
6.  From *main-server-group* *create child* *deployment*
    *Package Version*: 1.0
    *Deployment*: jboss-as-greeter.war
7.  Without changing the contents of the WAR file, upload a new version using the *new content* page of the jboss-as-greeter.war resource.
    1.  Select *Upload New Package*
    *Upload File*: jboss-as-greeter.war
    *Version*: 1.1
    *Repository*: None

Actual results:
Content history page shows that the discovered (initial or original) and updated version are both 1.1.

Expected results:
The discovered (initial or original) version should show 1.0 and the new/updated version should show 1.1.

Additional info:
This issue seems to stem from the fact that the new package does not get added to the RHQ_PACKAGE_VERSION table if a package with the same hash already exists. Essentially, it is detected that it is a duplicate and the existing row's version info is updated. 

However, because the RHQ_INSTALLED_PKG_HIST contains a foreign key relationship between the audit entry row and the package version entry in RHQ_PACKAGE_VERSION, the result is that each row in RHQ_INSTALLED_PKG_HIST which represents a distinct version end up referencing the same package version row.

For example, using the following SQL where <RESOURCE_ID> is the ID of the resource content was created:

    SELECT iph.HISTORY_TIMESTAMP, iph.STATUS, pv.* FROM RHQ_INSTALLED_PKG_HIST AS iph LEFT JOIN RHQ_PACKAGE_VERSION AS pv ON pv.ID = iph.PACKAGE_VERSION_ID WHERE iph.RESOURCE_ID=<RESOURCE_ID> ORDER BY iph.HISTORY_TIMESTAMP;

Reveals the following results:

    history_timestamp	status	id	display_name	short_description	long_description	version	display_version	file_name	file_size	file_md5	file_sha256	file_creation_time	license_name	license_version	metadata	package_id	architecture_id	config_id	package_bits_id
    1373657355770	DISCOVERED	10011	<null>	<null>	<null>	[sha256=ad85db1908db601970f399174458bab412c81640ea47b026ebc1698c7cb27828]	<null>	jboss-as-greeter.war	18154	<null>	ad85db1908db601970f399174458bab412c81640ea47b026ebc1698c7cb27828	<null>	<null>	<null>	<null>	10001	1	<null>	<null>


But as soon as we update to version 1.1 we end up with:

    history_timestamp	status	id	display_name	short_description	long_description	version	display_version	file_name	file_size	file_md5	file_sha256	file_creation_time	license_name	license_version	metadata	package_id	architecture_id	config_id	package_bits_id
    1373657355770	DISCOVERED	10011	<null>	<null>	<null>	[sha256=ad85db1908db601970f399174458bab412c81640ea47b026ebc1698c7cb27828]	1.1	jboss-as-greeter.war	18154	50a9f24fc3e0d5df8556d708fa364276	ad85db1908db601970f399174458bab412c81640ea47b026ebc1698c7cb27828	1373658959668	<null>	<null>	<null>	10001	1	<null>	10012
    1373659028780	BEING_INSTALLED	10011	<null>	<null>	<null>	[sha256=ad85db1908db601970f399174458bab412c81640ea47b026ebc1698c7cb27828]	1.1	jboss-as-greeter.war	18154	50a9f24fc3e0d5df8556d708fa364276	ad85db1908db601970f399174458bab412c81640ea47b026ebc1698c7cb27828	1373658959668	<null>	<null>	<null>	10001	1	<null>	10012
    1373659030265	INSTALLED	10011	<null>	<null>	<null>	[sha256=ad85db1908db601970f399174458bab412c81640ea47b026ebc1698c7cb27828]	1.1	jboss-as-greeter.war	18154	50a9f24fc3e0d5df8556d708fa364276	ad85db1908db601970f399174458bab412c81640ea47b026ebc1698c7cb27828	1373658959668	<null>	<null>	<null>	10001	1	<null>	10012


Pay special attention to the "id" column as this is how the two tables get linked (package_version_id = id). Also notice the values for "display_version" and "file_creation_time". In the first result set "display_version" and "file_creation_time" are not set. But in the second, the already existing history row now reflects values from the updated version in the newly added history row.

Another observation is that even though you specify version of 1.0, this does not get applied to the initial content version.

I have attached screen shots of the content history page for reference.
Comment 1 Larry O'Leary 2013-07-12 18:33:34 EDT
Created attachment 772904 [details]
Content History page when same file is uploaded by as version is 1.1
Comment 2 Lukas Krejci 2013-10-03 07:10:52 EDT
One of the fundamental assumptions of the content subsystem as it stands today is that there exists at most 1 package version identified by its name, version (which contains the SHA256), package type and architecture.

The "version" provided in the reproduction steps above is understood to be the "displayVersion" of the package version and is NOT part of the package resolution. The ContentManagerBean#createPackageVersion() method checks whether a package version with given name + sha + packagetype + arch already exists. If it DOES exist, the method, funnily enough, updates the display version of the existing package version with the provided data and returns the existing package version. 

This is consistent with the findings above and this behavior has been introduced as a part of the fix for BZ 771418.

Stefan, being the author of the fix for BZ 771418, should be able to shed more light into this.
Comment 4 Stefan Negrea 2014-02-13 09:14:45 EST
Lukas correctly pointed out the limitation of the current content subsystem in comment #2. 

When a user uploads a package with identical content, the content subsystem does a soft override of the display version only to keep the system in a consistent state with the latest user actions.

The only criteria for judging correctness for the content subsystem is that the content being deployed and presented as deployed is correct. Due the many design limitations, the history is not an immutable log of what happened to a resource (although it correctly logs the content deployed to the resource over the lifespan of the resource). There was a compromise to keep showing the display version to users to make it easier to spot if the version currently deployed matches their expectations. The display version is only informational and does not uniquely identify content.

The reported behaviour is consistent with all the recent fixes and does not affect the correctness of the content deployed and active. The reported behaviour cannot be fixed without a major redesign of the content subsystem.

Note You need to log in before you can comment on or make changes to this bug.