Bug 821910

Summary:

Migration causes jboss apps to 404

Product:

OKD

Reporter:

Kenny Woodson <kwoodson>

Component:

Containers

Assignee:

Bill DeCoste <wdecoste>

Status:

CLOSED CURRENTRELEASE

QA Contact:

libra bugs <libra-bugs>

Severity:

low

Docs Contact:

Priority:

low

Version:

2.x

CC:

dmace, rmillner, xtian

Target Milestone:

---

Keywords:

Triaged

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2012-06-25 18:27:13 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:

Attachments:

Description	Flags
output from app status script	none

Description Kenny Woodson 2012-05-15 18:02:31 UTC

Description of problem:

Before our release we attempted to capture the status of active applications.  This is done by capturing the application's http return code.  After we are done with migrations, we run the same script which captures the status after our migrations.

After looking at the results of our script we noticed there were over 80 applications whose status changed.  These are mostly JBoss applications. (+90% are jboss)

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

Current as of May 15, 2012

How reproducible:

Very reproducible.  

Steps to Reproduce:
1. Capture the http return code of an http request to a jboss application 
2. Migrate a jboss application.
3. Repeat step 1 and compare the results.
  
Actual results:

The return codes are going from 200 to 404.

Expected results:

The migration should leave the applications in the same state as before.

Additional info:

Comment 1 Kenny Woodson 2012-05-15 18:08:23 UTC

Created attachment 584741 [details]
output from app status script

Comment 2 Bill DeCoste 2012-05-15 18:27:27 UTC

Do we have access to any of the jboss logs for the failed applications? I have one JBoss app running in prod that was stopped when I just checked. When I started it, it came up fine. I can't think of anything that would break existing apps - the only changes in this sprint were for new applications and increasing the timeout for JBoss apps to start.

Comment 3 Bill DeCoste 2012-05-29 18:07:23 UTC

Where are we with this bug?

Comment 4 Kenny Woodson 2012-05-30 17:32:03 UTC

We are currently in the same spot as jboss logs from these applications are restricted unless we further obtain permission from the users.

Comment 5 Bill DeCoste 2012-05-30 19:51:03 UTC

Lowering severity as not actionable

Comment 6 Bill DeCoste 2012-06-07 14:13:11 UTC

Have increased the deployment scanner timeout from 2 to 5 mins. The sprint 12 migration ran into several applications that returned a 404 post-migration. Speculation is that the number of applications being restarted at once during a migration slows the normal application deployment time.

Comment 7 Xiaoli Tian 2012-06-11 09:18:01 UTC

Have tried to update with the latest stage candidate build and migrate with version 2.0.12

Will still meet some 404 after migration:

HTTP/1.1 200 OK
Date: Mon, 11 Jun 2012 08:03:23 GMT
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"6738-1339399688000"
Last-Modified: Mon, 11 Jun 2012 07:28:08 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 6738
Vary: Accept-Encoding,User-Agent
Strict-Transport-Security: max-age=15768000, includeSubDomains
ProxyTime: D=3074
Connection: close

HTTP/1.1 404 Not Found
Date: Mon, 11 Jun 2012 08:38:12 GMT
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 959
Vary: Accept-Encoding,User-Agent
Strict-Transport-Security: max-age=15768000, includeSubDomains
ProxyTime: D=3973
Connection: close


Let this bug open and try to verify it in migration in sprint 13

Comment 8 Xiaoli Tian 2012-06-17 11:11:45 UTC

Have tested it on devenv_1846, this does not happen again