Bug 911322

Summary:	JBoss Tools Plugin: Error message during removing an embedded cartridge
Product:	OKD	Reporter:	Andre Dietisheim <adietish>
Component:	Master	Assignee:	Lili Nader <lnader>
Status:	CLOSED CURRENTRELEASE	QA Contact:	libra bugs <libra-bugs>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	2.x	CC:	abhgupta, adietish, admiller, anagy, dmcphers, jinzhang, mfisher, mshao, rmillner
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	838611	Environment:
Last Closed:	2013-03-15 14:09:21 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:

Description Andre Dietisheim 2013-02-14 17:55:56 UTC

+++ This bug was initially created as a clone of Bug #838611 +++

Description of problem: Using JBoss Tools plugin adding / removing embedded cartridges produces a strange error-message.

Could not embed cartridges for application myphptestapp
Could not find link "DELETE" in resource "EmbeddedCartridgeResource"


Version-Release number of selected component (if applicable):\
devenv_1879 (ami-63228e0a)
Eclipse Juno
JBoss OpenShift Tools - 2.3.0.v20120613-1951-H135-Final	(installed from Eclipse Marketplace)


How reproducible: Always


Steps to Reproduce:
1. Create an OpenShift Application or import an existing one in Eclipse
2. Open OpenShift Explorer
3. Right click on the application name and select 'Edit Embedded Cartridges'
  

Actual results: The error-message above is shown. At the second attempt the cartridge will be added successfully. Removing an already embedded cartridge produces the same issue; the error-message above is shown, but actually the embedded cartridge is successfully removed.


Expected results: Adding / removing embedded cartridge must be successfully.


Additional info: On current production environment this feature works well without strange error-messages.

--- Additional comment from Abhishek Gupta on 2012-07-09 15:21:07 EDT ---

Note: I need more information on what, if anything, needs to be changed/fixed on the backend side.

The REST API does return the 'DELETE' link for the cartridge, whether one is querying for a single cartridge or the entire list of cartridges. The links are also returned when the cartridge structure is returned at the time of embedding it in the application. I have pasted below the link structure for both json and xml. 


"DELETE":{"required_params":[],"optional_params":[],"rel":"Delete embedded cartridge","method":"DELETE","href":"https://localhost/broker/rest/domains/agupta130/applications/app1/cartridges/mysql-5.1"}


<link>
  <required-params/>
  <rel>Delete embedded cartridge</rel>
  <optional-params/>
  <method>DELETE</method>
  <href>https://localhost/broker/rest/domains/agupta130/applications/app1/cartridges/mysql-5.1</href>
</link>

--- Additional comment from Abhishek Gupta on 2012-07-09 15:22:49 EDT ---

Max Anderson: Can you please look into this bug and comment?

--- Additional comment from Lili Nader on 2012-07-09 18:19:14 EDT ---

I sent email to JBoss tools team to take a look at this bug.

--- Additional comment from Attila Nagy on 2012-07-11 04:55:56 EDT ---

From broker log:

Started GET "/broker/rest/domains/myd2012071101/applications/redmine2/cartridges" for 209.132.186.34 at Wed Jul 11 04:25:39 -0400 2012
  Processing by EmbCartController#index as JSON
  Parameters: {"application_id"=>"redmine2", "domain_id"=>"myd2012071101"}
MongoDataStore.find(CloudUser, anagy+2012071101, anagy+2012071101)

Getting cartridges for application redmine2 under domain myd2012071101
[REQ_ID=cceaccc552b64786a79d369826d19e43] ACTION=LIST_APP_CARTRIDGES Listing cartridges for application redmine2 under domain myd2012071101
Completed 200 OK in 60ms (Views: 17.4ms)

In the response I could find a link about deletion.

...
<links>
        <link>
          <href>https://ec2-23-22-173-85.compute-1.amazonaws.com/broker/rest/domains/myd2012071101/applications/redmine2/cartridges/mysql-5.1</href>
          <optional-params/>
          <rel>Delete embedded cartridge</rel>
          <method>DELETE</method>
          <required-params/>
        </link>
...

I'll attached the full response in XML format.

--- Additional comment from Attila Nagy on 2012-07-11 04:56:48 EDT ---

Created attachment 597508 [details]
full response

--- Additional comment from Andre Dietisheim on 2012-07-11 10:45:50 EDT ---

I could track the problem down to a semantical change in the REST responses in the latest DEVENV:

if you request the embedded cartridges for a given app, you'll get the application type, too, which is not the case in PROD now.

Example:

I have an application "tata" with no embedded cartridges running on my DEVENV:

{
    ...
    "name" => "tata",
    ...
    "framework" => "jbossas-7",
    ...
}

If I request it's embedded cartridges, I'll GET the following link and get the list of embedded cartridges:

       "LIST_CARTRIDGES" => {
            "href" => "https://ec2-23-22-173-85.compute-1.amazonaws.com/broker/rest/domains/holymoly/applications/tata/cartridges",
            "optional_params" => [],
            "rel" => "List embedded cartridges",
            "method" => "GET",
            "required_params" => []
        },

In PROD, I'll get an empty list. In my DEVENV, I get a list with a single entry, the appliction type (cartridge):

{
   "type":"cartridges",
   "status":"ok",
   ...
   "data":[
      {
      ...
         "name":"jbossas-7",
         "type":"standalone",
         ...

On the other hand, if we request the available embeddable cartridges on the API resource, we'll only get the embeddable cartridges, no application type (cartridges).

There's no problem for us to handle this change, but we can't do that for our existing userbase. They would be stuck in a Eclipse tooling that is not able to add/remove cartridges. We'd have to update their client. 

IMHO with this change in place you'd have to bump up the protocol version and make sure our userbase would still get the prior protocol. I double checked, we still send "Accept: application/json; version=1.0".

--- Additional comment from Krishna Raman on 2012-07-11 17:57:37 EDT ---

https://github.com/openshift/crankcase/pull/224

--- Additional comment from Adam Miller on 2012-07-11 20:33:28 EDT ---

Merged.

--- Additional comment from Attila Nagy on 2012-07-12 08:13:14 EDT ---

Verified against ami-ab72ddc2.

Comment 1 Andre Dietisheim 2013-02-14 18:00:43 UTC

As per 13th of Feb 2013 this issue is occurring again:

Do 

As per yesterday this issue can be reproduced again:

curl -k -H "Accept: application/xml; version=1.0" --user "<username>:<password>" https://openshift.redhat.com/broker/rest/domains/<domain>/applications/<application-name>/cartridges -X GET

And you get the application type reported in the cartridges even though we're talking protocol 1.0:

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <status>ok</status>
  <type>cartridges</type>
  <data>
    <cartridge>
      <name>jbossas-7</name>
      <type>standalone</type>
      <status-messages nil="true"></status-messages>
      <properties>
      </properties>
    </cartridge>
  </data>
  <messages/>
  <version>1.0</version>
  <supported-api-versions>
    <supported-api-version>1.0</supported-api-version>
    <supported-api-version>1.1</supported-api-version>
    <supported-api-version>1.2</supported-api-version>
    <supported-api-version>1.3</supported-api-version>
  </supported-api-versions>
</response>

The fix for this issue back when it appeared for the first time, was to report embedded cartridges only when requesting /applications/<application-name>/cartridges while in protocol 1.0. Protocol 1.1 on the other hand would report the application-type (standalone-cartridge) and all the embedded cartridges.

Comment 2 Lili Nader 2013-02-14 21:18:12 UTC

https://github.com/openshift/origin-server/pull/1374

Comment 3 JBoss JIRA Server 2013-02-15 12:47:16 UTC

Andre Dietisheim <adietish> made a comment on jira JBIDE-13561

There is a regression in OpenShift that leaks behavior from protocol 1.1 to 1.0. All existing JBDS/JBT users are affected:

If you list the cartridges of one of your applications
{code}
curl -k -H "Accept: application/xml; version=1.0" --user "USERNAME:PASSWORD" https://openshift.redhat.com/broker/rest/domains/myops/applications/kitch/cartridges -X GET
{code}

You get the application type (and embedded cartridges there are)
{code}
<?xml version="1.0" encoding="UTF-8"?>
<response>
  <status>ok</status>
  <type>cartridges</type>
  <data>
    <cartridge>
      <name>jbossas-7</name>
      <type>standalone</type>
      <status-messages nil="true"></status-messages>
      <properties>
      </properties>
    </cartridge>
  </data>
  <messages/>
  <version>1.0</version>
  <supported-api-versions>
    <supported-api-version>1.0</supported-api-version>
    <supported-api-version>1.1</supported-api-version>
    <supported-api-version>1.2</supported-api-version>
    <supported-api-version>1.3</supported-api-version>
  </supported-api-versions>
</response>
{code}

In https://bugzilla.redhat.com/show_bug.cgi?id=838611 this request was fixed to only return embeddable cartridges in protocol 1.0, not the standalone/application-type.

Comment 4 joycezhang 2013-02-16 04:08:13 UTC

QE will verify this bug when the pull request get merged successfully.

Comment 5 Lili Nader 2013-02-18 23:50:49 UTC

fixed in staging https://github.com/openshift/origin-server/pull/1399

Comment 6 joycezhang 2013-02-19 03:22:53 UTC

Verified this bug on devenv-stage-296 as below:

Verified build:
devenv-stage-296
Eclipse Juno
JBoss OpenShift Tools - 2.4.0.Final-v20130218-1429-B116

Verified steps:
1. Create an OpenShift Application or import an existing one in Eclipse
2. Embed a cartridge for this app like switch-yard, mongodb and etc.

Actual results:
The error is not shown anymore, the cartridges can be added to the app successfully.


Using rest api to get cartridges as below:
# curl -k -H 'Accept: application/xml; version=1.0' --user jinzhang+3:redhat 'https://184.72.86.133/broker/rest/domains/stg296dm1/applications/jbsas1app1/cartridges/' -X GET
<?xml version="1.0" encoding="UTF-8"?>
<response>
  <status>ok</status>
  <type>cartridges</type>
  <data/>
  <messages/>
  <version>1.0</version>
  <supported-api-versions>
    <supported-api-version>1.0</supported-api-version>
    <supported-api-version>1.1</supported-api-version>
    <supported-api-version>1.2</supported-api-version>
    <supported-api-version>1.3</supported-api-version>
  </supported-api-versions>
</response>

Comment 7 joycezhang 2013-02-19 04:00:50 UTC

Updated more information for above comments, it worked well for both add and remove cartridges for apps.

Comment 8 JBoss JIRA Server 2013-02-21 16:10:24 UTC

Andre Dietisheim <adietish> made a comment on jira JBIDE-13561

PROD was fixed, it does not show the application type (cartridge) in the list of embedded cartridges any more:

!cartridge-type-not-embedded.png!

Closing this watcher issue.

Comment 9 JBoss JIRA Server 2013-02-21 16:10:52 UTC

Andre Dietisheim <adietish> updated the status of jira JBIDE-13561 to Resolved

Comment 10 JBoss JIRA Server 2013-02-26 15:03:38 UTC

Stefan Bunciak <sbunciak> updated the status of jira JBIDE-13561 to Closed

Comment 11 JBoss JIRA Server 2013-02-26 15:03:38 UTC

Stefan Bunciak <sbunciak> made a comment on jira JBIDE-13561

Verified in JBoss Developer Studio

Version: 7.0.0.Alpha1
Build id: Alpha1-v20130225-0422-B62
Build date: 20130225-0422

Comment 12 Andre Dietisheim 2013-03-05 16:50:06 UTC

This started to show up again on INT:

curl -k --user "<USER>:<PASS>" -H "Accept: application/xml; version=1.0" https://int.openshift.redhat.com/broker/rest/domains/freaky/applications/1362496644059/cartridges -X GET
<?xml version="1.0" encoding="UTF-8"?>
<response>
  <status>ok</status>
  <type>cartridges</type>
  <data>
    <cartridge>
      <name>jbossas-7</name>
      <type>standalone</type>
      <status-messages nil="true"></status-messages>
      <properties>
      </properties>
    </cartridge>
  </data>
  <messages/>
  <version>1.0</version>
  <supported-api-versions>
    <supported-api-version>1.0</supported-api-version>
    <supported-api-version>1.1</supported-api-version>
    <supported-api-version>1.2</supported-api-version>
    <supported-api-version>1.3</supported-api-version>
  </supported-api-versions>
</response>

Comment 13 Dan McPherson 2013-03-05 16:58:09 UTC

Lili, can you make sure test cases get added for this case.

Also note the build in INT as per admiller's note is from last Friday.  Given when this fix was made I don't think that's the issue here.

-Dan

Comment 14 Lili Nader 2013-03-05 20:16:13 UTC

The fix for this bug was reverted when I reverted the US2448 (alias with SNI).  I am working on adding it back in.
Lili

Comment 15 Lili Nader 2013-03-06 08:50:05 UTC

https://github.com/openshift/origin-server/pull/1561

Comment 16 openshift-github-bot 2013-03-06 16:06:42 UTC

Commits pushed to master at https://github.com/openshift/origin-server

https://github.com/openshift/origin-server/commit/362768aea42cfb0b5c22efae3fed776f9652394a
Bug 911322

https://github.com/openshift/origin-server/commit/10a7bfbedc5a4b031285331da0f8e6ffac257dd7
Merge pull request #1561 from lnader/master

Bug 911322

Comment 17 joycezhang 2013-03-07 10:03:21 UTC

Verified this bug on devenv-2905 as below:

Verified build:
devenv-2905
Eclipse Juno
JBoss OpenShift Tools - 2.4.0.Final-v20130302-0204-B128

Verified steps:
1. Create an OpenShift Application or import an existing one in Eclipse
2. Embed a cartridge for this app like switch-yard, mongodb and etc.
3. Remove the embeded cartridges.

Actual results:
The error is not shown anymore, the cartridges can be added and removed from the app successfully.


Using rest api to get cartridges as below:
# curl -k -H "Accept: application/xml; version=1.0" --user "jinzhang+4:redhat" https://ec2-54-234-157-88.compute-1.amazonaws.com/broker/rest/domains/dmt4new/applications/j27s/cartridges  -X GET

<?xml version="1.0" encoding="UTF-8"?>
<response>
  <status>ok</status>
  <type>cartridges</type>
  <data/>
  <messages/>
  <version>1.0</version>
  <supported-api-versions>
    <supported-api-version>1.0</supported-api-version>
    <supported-api-version>1.1</supported-api-version>
    <supported-api-version>1.2</supported-api-version>
    <supported-api-version>1.3</supported-api-version>
  </supported-api-versions>
</response>

Comment 18 Andre Dietisheim 2013-03-07 11:10:26 UTC

I can confirm, I dont see this happening any more when using INT