Bug 889250 - EAP 6 domain mode - stale history of content of deployment on server group when content of dependent domain deployment is upgraded
Summary: EAP 6 domain mode - stale history of content of deployment on server group wh...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Content, Plugin -- JBoss EAP 6
Version: JON 3.1.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: DR01
: JON 3.3.0
Assignee: Libor Zoubek
QA Contact: Filip Brychta
URL:
Whiteboard:
Depends On: JON3-25, PRODMGT-368
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-20 15:39 UTC by Filip Brychta
Modified: 2015-11-02 00:43 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-12-11 14:04:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1069691 0 unspecified CLOSED DomainDeployments should be managed in a single menu option in domain mode 2021-02-22 00:41:40 UTC

Internal Links: 1069691

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.


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