Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 889250

Summary:	EAP 6 domain mode - stale history of content of deployment on server group when content of dependent domain deployment is upgraded
Product:	[JBoss] JBoss Operations Network	Reporter:	Filip Brychta <fbrychta>
Component:	Content, Plugin -- JBoss EAP 6	Assignee:	Libor Zoubek <lzoubek>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Filip Brychta <fbrychta>
Severity:	high	Docs Contact:
Priority:	high
Version:	JON 3.1.2	CC:	hrupp, lzoubek, myarboro, theute
Target Milestone:	DR01
Target Release:	JON 3.3.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-12-11 14:04:37 UTC	Type:	Bug
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:	1069691
Bug Blocks:

Description Filip Brychta 2012-12-20 15:39:15 UTC

Description of problem:
When upgrading domain deployment, deployment on dependent server group is correctly upgraded as well, but his content history is stale (old content hash) and history is never updated.

Version-Release number of selected component (if applicable):
3.1.2.ER5

How reproducible:
Always

Steps to Reproduce:
1. clean JON installation, eap6 is running in domain mode and is imported to JON inventory
2. create a new domain deployment helloworld.war - navigate to EAP Domain Controller->Inventory->CreateChild->DomainDeployment
3. assign this domain deployment to some server group (domain deployment resource->operations->assign to server group)
4. Launch manual autodiscovery to see the new deployment on the server group (platform resource->Operations->Manual Autodiscovery)
5. the new deployment helloworld.war is visible on the server group in JON UI
6. upgrade helloworld.war domain deployment (content of helloworld.war must be changed) - navigate to EAP Domain Controller->Domain deployments->helloworld.war->Content->New->Upload new package
7. you can see that helloworld.war was upgraded (in content history tab), new version has different hash, new version is redeployed on server group (visible in EAP logs and checked the new content of helloworld.war in browser)
8. manual autodiscovery (step 4)
9. navigate to content history tab - EAP Domain Controller->ServerGroups->your-server-group->Deployments->helloworld.war->Content->History

  
Actual results:
There is a stale hash of helloworld.war and no history changes.
So to sum up, helloworld.war was correctly upgraded on server group (i can see upgraded content of index.jsp in browser), but JON shows the hash of previous version and no history changes.

Expected results:
Jon shows correct history of helloworld.war on server group. That means the history of deployment on server group should be the same as history of dependent domain deployment.

Comment 1 Thomas Segismont 2013-09-12 08:16:21 UTC

After a package is deployed, the plugin container executes an immediate content discovery on the corresponding resource (see org.rhq.core.pc.content.CreateContentRunner#call line 116). This is why the content history is updated on the "EAP the Domain Controller->Domain deployments" resource.

However, the "EAP Domain Controller->ServerGroups->your-server-group->Deployments" resource content is updated only when a new content discovery scan is executed. This happens every 12 hours.

A possible fix could be to extend the DeployPackagesResponse object to let a resource component specify a list of resource ids or resource types for which a discovery scan is necessary. But this cannot happen in 3.2 time-frame IMO.

I'm setting the target release to 3.3.

Comment 2 Thomas Segismont 2013-09-12 08:53:40 UTC

(In reply to Thomas Segismont from comment #1)
> A possible fix could be to extend the DeployPackagesResponse object to let a
> resource component specify a list of resource ids or resource types for
> which a discovery scan is necessary. But this cannot happen in 3.2
> time-frame IMO.

This would work only for domains managed by the same agent. We also need to think about deployments where slave host controllers are not installed on the same machine as the domain controller (thus being managed by a another agent).

Comment 3 Simeon Pinder 2014-07-31 15:52:15 UTC

Moving to ON_QA as available to test with brew build of DR01: https://brewweb.devel.redhat.com//buildinfo?buildID=373993

Comment 4 Filip Brychta 2014-08-04 10:37:49 UTC

Verified on
Version :	
3.3.0.DR01
Build Number :	
6468454:dda0a47

This is no longer an issue because of the bz 1069691.
I verified that it is possible to update domain deployment.