+++ 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.
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.
https://github.com/openshift/origin-server/pull/1374
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.
QE will verify this bug when the pull request get merged successfully.
fixed in staging https://github.com/openshift/origin-server/pull/1399
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>
Updated more information for above comments, it worked well for both add and remove cartridges for apps.
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.
Andre Dietisheim <adietish> updated the status of jira JBIDE-13561 to Resolved
Stefan Bunciak <sbunciak> updated the status of jira JBIDE-13561 to Closed
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
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>
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
The fix for this bug was reverted when I reverted the US2448 (alias with SNI). I am working on adding it back in. Lili
https://github.com/openshift/origin-server/pull/1561
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
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>
I can confirm, I dont see this happening any more when using INT