Bug 752416

Summary:	API configchannel.createOrUpdatePath returns questionable modified field
Product:	Red Hat Satellite 5	Reporter:	Šimon Lukašík <slukasik>
Component:	API	Assignee:	Tomas Lestach <tlestach>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Martin Korbel <mkorbel>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	550	CC:	jpazdziora, mkorbel, mminar
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	spacewalk-java-1.7.54-24	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-09-21 09:19:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	818987

Description Šimon Lukašík 2011-11-09 13:05:54 UTC

Description of problem:
There are multiple API calls, which returns ConfigRevision objects. In some
use case, user should get the very same object from different API call.

For instance, when user creates multiple file revisions of a given file
by API call configchannel.createOrUpdatePath. The exactly same revisions
should be returned by configchannel.getFileRevisions API call.

The problem is that they might differ in the 'modified' item. Revisions
returned by configchannel.createOrUpdatePath API call might have 'modified'
time of 1 second earlier ... compared to configchannel.getFileRevisions.

Version-Release number of selected component (if applicable):
Spacewalk 1.5
Spacewalk nightly

How reproducible:
not deterministic, but easily reproducible

Steps to Reproduce:
1. Call configchannel.createOrUpdatePath for a given file
   with some arbitrary values.
2. save a return value (struct - Configuration Revision information)
3. repeat a few times
4. Compare these saved values with configchannel.getFileRevisions API call

Actual results:
Revisions sometimes differs in 'modified' item.

Expected results:
Revisions are equal.


Additional info:

Comment 1 Šimon Lukašík 2011-11-09 13:11:53 UTC

Investigation:

The problem is that spacewalk-java sets the 'modified' field during
a construction of ConfigurationRevision object, returns it to the user, and
attempts to store it in the database. Unfortunately, in the database, there is
a trigger which overrides 'modified' field on insert.

Comment 3 Tomas Lestach 2011-12-16 10:48:41 UTC

Hey Simon,

now I'm not sure, what version you have the trouble with.

The reason is, we've fixed Bug 593300, that shall not create another file revision, if the new one doesn't differ from the previous one. At the time, you've reported the bug was the 593300 already fixed.

Is it possible that your problem was fixed with 593300 fix?

Comment 4 Šimon Lukašík 2011-12-16 11:52:20 UTC

I believe that this problem was not addressed by fix for bug 593300.

Comment 5 Jan Pazdziora (Red Hat) 2011-12-16 13:06:36 UTC

(In reply to comment #3)
> Hey Simon,
> 
> now I'm not sure, what version you have the trouble with.
> 
> The reason is, we've fixed Bug 593300, that shall not create another file
> revision, if the new one doesn't differ from the previous one. At the time,
> you've reported the bug was the 593300 already fixed.
> 
> Is it possible that your problem was fixed with 593300 fix?

From Šimon's description it looks like you create one timestamp in the Java stack and return that when creating the revision. But in the database (and thus returned by subsequent calls that properly retrieve the object from the database), the value is set by the trigger, and depending on the load on the Spacewalk machine, you have nonzero chance that the trigger will fire after the second "ticks".

Any chance of not setting the modified value in Java at all?

Are the other API calls that use the same workflow and could have the same problem?

Comment 6 Jan Pazdziora (Red Hat) 2012-02-24 16:02:44 UTC

Tomáš, ping?

Comment 7 Tomas Lestach 2012-03-23 13:39:11 UTC

pong

fixed

spacewalk.git: 9f312438c263899b64fc218e0ae707f5a46f21f1

howg

Comment 13 Clifford Perry 2012-09-21 09:19:24 UTC

This issue is resolved with the release of RHN Satellite 5.5. 

As of September 20th 2012, RHN Satellite 5.5 has been generally available. 

Release Notes and other 5.5 documentation can be found here:

 https://access.redhat.com/knowledge/docs/Red_Hat_Network_Satellite/

The associated Errata for the 5.5 release are:

5.5 Satellite GA Errata
 - http://rhn.redhat.com/errata/RHEA-2012-1296.html

5.5 Upgrade Errata
 - http://rhn.redhat.com/errata/RHEA-2012-1298.html

5.5 RHN Proxy GA Errata
 - http://rhn.redhat.com/errata/RHEA-2012-1297.html

5.5 RHN Tools GA Errata
 - http://rhn.redhat.com/errata/RHEA-2012-1299.html

Regards,
Clifford
- Engineering Manager, Satellite