Description of problem:
When applying a patch to EAP, the zip file which should be downloaded by the agent from the JON server, does not end up in the expected location.
2010-06-15 00:14:48,332 INFO [ResourceContainer.invoker.nonDaemon-23] (jboss.on.common.jbossas.AbstractJBossASContentFacetDelegate)- Attempting to deploy package: PackageDetails[Key=PackageDetailsKey[Name=JBoss EAP 4.2.0.GA_CP09, Version=4.2.0.GA_CP09 Arch=noarch Type=cumulativePatch]]
2010-06-15 00:14:48,592 INFO [ResourceContainer.invoker.nonDaemon-23] (jbossnetwork.product.jbpm.handlers.JONServerDownloadActionHandler)- Description of step : Download file from the server and save it to [/tmp/jon_download2679847159410562741/JBEAP4.2.0_CP09/jboss-4.2.0.GA_CP09.zip].
2010-06-15 00:14:48,592 ERROR [ResourceContainer.invoker.nonDaemon-23] (jbossnetwork.product.jbpm.handlers.JONServerDownloadActionHandler)- Result of step : message[null]
No messages in the server log.
The jon_download* dir in /tmp is created:
[ozizka@jawa18 jboss-web-cluster.sar]$ ls /tmp/jon_download2679847159410562741/ -la
drwxrwxr-x 2 ozizka ozizka 4096 Jun 15 00:14 .
drwxrwxrwt 21 root root 4096 Jun 15 00:14 ..
1) Install JON 2.3.0 and JBoss AS/EAP plugins.
2) Install EAP 4.2.0 and let an agent monitor it.
3) tail -f rhq_agent/logs/rhq_agent.log
4) Register JBoss Patch source and install EAP 4.2.9 dist-diff patch.
5) Wait for the exception in agent's log.
Used "all" JBoss EAP profile.
EAP 4.2 CP09 patch is at
Created attachment 423993 [details]
Agent's system: RHEL 5 @ jawa18.englab.brq.redhat.com
running under a regular user
Blocks EAP patches verification for CSP.
I don't think this is a problem with copy files, more likely to be an issue with downloading the files in the first place.
One idea though, is /tmp on the same filesystem as where the agent is installed
No, /tmp is on local HDD, work dir is on NFS.
Note that this worked in Boston lab, where the setup was similar, regarding this.
server @ dev35.qa.atl2.redhat.com.
agent @ .qa.atl2.redhat.com (don't remember exactly)
I tried with access.redhat.com as Charles suggested in #5.
Now it fails because the downloaded "zip" is actually a HTML page, seems like the root page.
23:01:47) ozizka`: it's a HTML file named ... zip
(23:02:13) ozizka`: So, either wrong metadata or server misbehaving
(23:02:19) ozizka`: other ideas?
(23:03:13) spinder: ozizka`: Or the CSP feed element is not being served up correctly.
(23:05:10) ozizka`: spinder: That's what I mean by metadata.
For the record -
Digest of [/tmp/jon_download4495698412119601228/jboss-4.3.0.GA_CP01.zip] is [50696e977bf2751e602f3c497c3521ca] and does not match expected value [0c3284c13efc48eb5f43f755b23f0d5c]
Identified as CSP stage repo problem.
See JBQA-3439 -
AMS has diagnosed issue:
When referencing the URL provided in the stage environment, the browser is looking for a string on cookie "ChromeLocale" and failing on line 28 in the code when the call fails. Upon further investigation, the cookie is not assigned in WebQA and Stage environments. This is because, the cookie is an automated assignment from Redhat.com when a requestor attempts to access a URL with the pattern access.redhat.com.
In Stage, automated cookie assignment is not configured. Therefore, all requests to the URL for "ChromeLocale" will fail, because the source of this data is not available.
Possible resolutions at this point:
1) Remove the call for "ChromeLocale" from Stage and WebQA
2) Configure automatic cookie assignment in Stage and WebQA
3) Manufacture a cookie with the required data for internal users.
AMS is investigating which option is fastest to market.
cccrouch - what to do with this? needs to be reassigned to CSP?
I think the problem at CSP side is solved.
Igor, what's the current state pls?
Well it's mostly possible for JON to succesfully download the zip. But failures(0B zip files) are still occuring from time to time with stage csp, especially with bigger files(but every time it worked after re-trying).
Is that still an issue, as there have been a lot of changes and improvements since?