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:
Created attachment 584741 [details] output from app status script
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.
Where are we with this bug?
We are currently in the same spot as jboss logs from these applications are restricted unless we further obtain permission from the users.
Lowering severity as not actionable
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.
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
Have tested it on devenv_1846, this does not happen again