Bug 804937 - The cartridge_types page shows cartridges installed but they are not installed actually on stage
Summary: The cartridge_types page shows cartridges installed but they are not installe...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OKD
Classification: Red Hat
Component: Website
Version: 2.x
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Clayton Coleman
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-20 09:01 UTC by Yujie Zhang
Modified: 2015-05-15 01:06 UTC (History)
5 users (show)

Fixed In Version: rhc-site-0.89.9-1+
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-08 17:58:53 UTC
Target Upstream Version:


Attachments (Terms of Use)
The snapshot of adding mysql. (46.19 KB, image/png)
2012-05-14 07:18 UTC, yquan
no flags Details

Description Yujie Zhang 2012-03-20 09:01:28 UTC
Description of problem:

After I created an application without adding any cartridges, click the Details link and click the Add link on details page, the /cartridge_types page does not match the details of applications sometimes, it will show that some cartridges are already installed.If I cleared my cookies and sign in again, sometimes the page will return normal, sometimes it will not.

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

How reproducible:randomly

Steps to Reproduce:
1.Go to openshift website and log in
2.Create an application and go the the details page of this application
3.Try to add a cartridge of this application.
  
Actual results:

The /cartridge_types page does not match the details of applications sometimes.

Expected results:

The /cartridge_types page should match the details of applications sometimes.

Additional info:

This issue did not exist on devenv-stage_146.

Comment 1 Xiaoli Tian 2012-03-20 10:12:41 UTC
Not sure what code causes this regression, since it can not always reproduced, give it medium priority, but we do hope you could check what happened to it before push to production.

Thanks

Comment 2 Clayton Coleman 2012-03-26 15:51:38 UTC
Is this still happening?  I can't recreate it locally in my devenv.

Comment 3 Fabiano Franz 2012-03-29 21:05:09 UTC
Fixed.

Comment 4 Yujie Zhang 2012-03-30 06:41:20 UTC
(In reply to comment #3)
Tested this bug on devenv-stage_154, does not have this issue now, thanks.

Comment 5 Yujie Zhang 2012-03-31 05:47:21 UTC
(In reply to comment #3)
hi Fabiano, need to re-open this bug for I met this issue on stage again, still randomly, could you please check this again?

Comment 6 Xiaoli Tian 2012-03-31 06:05:54 UTC
It's so strange that it seems this bug only occurs on stage, it works well on all the devenv build and production (since it's failed on stage-2.0.7, but it works on production-2.0.7), could you please check what's different between devenv and stage about this?

Since it's not always, let me reduce its severity to low.

Comment 7 yquan 2012-04-28 09:55:00 UTC
It occurs again on stage-2.0.10, but it works on devenv-stage_183.

Comment 8 Clayton Coleman 2012-05-09 16:46:49 UTC
This looks like a two node issue, as if the broker is out of sync between the nodes, or there is a cache issue at play.

Comment 9 yquan 2012-05-14 07:18:11 UTC
I found an problem in stage, when I am trying to add the mysql to an app, it failed, and the error message is "You must create a Jenkins application as a server before you can add the Jenkins cartridge to an application". But it occurred just once.I can't reproduce it again. And I took the snapshot(badge6.png), and can refer to it.

Comment 10 yquan 2012-05-14 07:18:45 UTC
Created attachment 584266 [details]
The snapshot of adding mysql.

Comment 11 Clayton Coleman 2012-05-14 13:49:48 UTC
When we fixed this, my understanding was that the error code from the server would be a specific code to correspond to jenkins failing to be added.  However, what we are getting is 143, which is the generic "could not add cartridge due to node failure, retry".  We need a more specific error code to be set by the node on this failure (not 143) and then the UI needs to change to react specifically to that code.

Medium severity because we are displaying the wrong message to end users in error scenarios

Krishna, is this your code or the runtime teams?

Comment 12 Krishna Raman 2012-05-14 14:16:48 UTC
This is probably in broker code.

Comment 13 Krishna Raman 2012-05-14 19:38:51 UTC
https://github.com/openshift/crankcase/pull/37

Comment 14 Clayton Coleman 2012-05-14 22:18:55 UTC
I've gotta make a change first.

Comment 15 Clayton Coleman 2012-05-15 18:28:52 UTC
Have to fix this in bug 821915.  Closing this story out.  The REST API should return an exit code to the client that is 0

Comment 16 Clayton Coleman 2012-05-15 19:11:41 UTC
Fixed on my end

Comment 17 yquan 2012-05-16 07:23:58 UTC
It is not fixed on current stage.
I still can reproduce it.
The step of reproduce.
1.Log on the openshift website.
2.create two applications.
3.Add some cartridge to the first application, such as mysql,cron,monogdb.
4.Go to the second application's detail page, and go to cartridge type page.
5.If you saw the page is regular, you just refresh the page, it will reproduce this problem.

Comment 18 yquan 2012-05-16 07:58:59 UTC
I will test it again,after the new stage pushed.

Comment 19 yquan 2012-05-21 05:57:35 UTC
It still exists on int.openshift.redhat.com.
The step of reproduce(must follow this step):
1.create a jboss app
2.embed the mysql ,mectrics, monodb,rockmongo to the jboss app
3.create a php app
4.click the php app detail page
5.click the add cartridge page.
6.If the page is normal , please re refresh it again and again till the problem page is presented.

Comment 20 Clayton Coleman 2012-05-24 23:54:59 UTC
Can you get a screenshot and a copy of both site/development.log and broker/development.log when you reproduce this?

Comment 21 Yujie Zhang 2012-05-29 03:15:04 UTC
(In reply to comment #20)
Did not meet this issue on devenv_1806, I will test it again on stage.

Comment 22 Yujie Zhang 2012-06-04 11:44:08 UTC
Tested on stage, did not meet this issue, verify this bug.


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