Bug 603932 - JONServerDownloadActionHandler - zip file not copied to /tmp
Summary: JONServerDownloadActionHandler - zip file not copied to /tmp
Status: CLOSED WONTFIX
Alias: None
Product: RHQ Project
Classification: Other
Component: Agent   
(Show other bugs)
Version: 1.3.1
Hardware: All
OS: Linux
low
urgent vote
Target Milestone: ---
: ---
Assignee: Charles Crouch
QA Contact: Mike Foley
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 603787
TreeView+ depends on / blocked
 
Reported: 2010-06-14 22:24 UTC by Ondřej Žižka
Modified: 2015-02-01 23:26 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-07 14:57:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Agent log. (14.30 KB, text/plain)
2010-06-14 23:05 UTC, Ondřej Žižka
no flags Details

Description Ondřej Žižka 2010-06-14 22:24:34 UTC
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.

Agent log: 
----------

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 [1]: 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 [1]: 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
total 16
drwxrwxr-x  2 ozizka ozizka 4096 Jun 15 00:14 .
drwxrwxrwt 21 root   root   4096 Jun 15 00:14 ..
[ozizka@jawa18 jboss-web-cluster.sar]$


STR:

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.

Comment 2 Ondřej Žižka 2010-06-14 23:05:21 UTC
Created attachment 423993 [details]
Agent log.

Comment 3 Ondřej Žižka 2010-06-15 00:05:58 UTC
Agent's system:  RHEL 5 @ jawa18.englab.brq.redhat.com
running under a regular user

Comment 4 Ondřej Žižka 2010-06-30 21:39:02 UTC
Blocks EAP patches verification for CSP.

Comment 6 Charles Crouch 2010-06-30 21:49:33 UTC
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

Comment 7 Ondřej Žižka 2010-06-30 21:55:41 UTC
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)

Comment 8 Ondřej Žižka 2010-07-02 21:07:36 UTC
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.

Comment 9 Ondřej Žižka 2010-07-02 21:54:20 UTC
For the record -

Digest of [/tmp/jon_download4495698412119601228/jboss-4.3.0.GA_CP01.zip]  is [50696e977bf2751e602f3c497c3521ca] and does not match expected value  [0c3284c13efc48eb5f43f755b23f0d5c]

Comment 11 Tom Mirc 2010-07-19 19:07:50 UTC
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.

Comment 12 Corey Welton 2010-09-24 13:18:51 UTC
cccrouch - what to do with this? needs to be reassigned to CSP?

Comment 13 Ondřej Žižka 2010-09-28 12:02:38 UTC
I think the problem at CSP side is solved.
Igor, what's the current state pls?

Comment 14 igilany 2010-09-29 09:59:01 UTC
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).

Comment 16 Heiko W. Rupp 2013-09-25 13:02:21 UTC
Is that still an issue, as there have been a lot of changes and improvements since?

Comment 17 Heiko W. Rupp 2013-12-07 14:57:23 UTC
Outdated


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