Bug 1041338

Summary: Deployments are not shown in the DTGov Dashboard / Deployments table
Product: [JBoss] JBoss Fuse Service Works 6 Reporter: Stefan Bunciak <sbunciak>
Component: DT GovernanceAssignee: Eric Wittmann <eric.wittmann>
Status: CLOSED CURRENTRELEASE QA Contact: Stefan Bunciak <sbunciak>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 6.0.0 GACC: eric.wittmann, jpechane, ncross, soa-p-jira
Target Milestone: ER8   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Stefan Bunciak 2013-12-12 15:15:32 UTC
Description of problem:

* Deployments are not shown in the DTGov Dashboard /  Deployments table

Version-Release number of selected component (if applicable):
* 6.0.0.ER7

How reproducible:


Steps to Reproduce:
1. Install FSW
2. Deploy dtgov-workflows
3. Create new deployment via UI

Actual results:

Workflow overlord.demo.SimpleReleaseProcess is started, new task is created in Task Inbox but the Deployments table is empty (tried Firefox & Chrome).


Expected results:


Additional info:

Comment 1 Kurt T Stam 2013-12-13 19:55:18 UTC
I can reproduce this and am investigating why this broke.

Comment 2 Kurt T Stam 2013-12-13 20:02:46 UTC
Looks like no classifications are set on the artifact.

Comment 3 Eric Wittmann 2013-12-16 15:49:10 UTC
Looks like jbpm may have changed a bit.  

The classifiers were being properly set by the workflow, but those values were being clobbered by the QueryExecutor (which is the class that queries the s-ramp repo for changes and triggers the workflow).

The final step the QueryExecutor takes is updating the artifact with the process ID of the workflow it executed.  This code was not first refreshing the artifact meta-data, so the update was clobbering any changes made to the artifact meta-data by the workflow.

I suspect jbpm used to return immediately from the "Create Workflow" api call, but is now only returning once the workflow hits a quiescence point.  Alternatively we've simply had a race condition there since day one and are only hitting it now for some reason.

Fixed now by refreshing the artifact meta-data prior to updating its property.

Comment 4 Jiri Pechanec 2014-01-23 06:42:19 UTC
Verified in CR1