Description of problem: When querying an application, the (embedded) cartridges are reported without any info. We especially miss the URL. Version-Release number of selected component (if applicable): protocol version "1.0" How reproducible: always Steps to Reproduce: 1. Have an application with embedded cartridges 2. curl -k -H "Accept: application/json" --user "<USER>:<PASSWORD>" https://openshift.redhat.com/broker/rest/domains/myops/applications/ Actual results: ... "embedded":{ "mongodb-2.2":{ "info":{ } }, "rockmongo-1.1":{ "info":{ } }, "phpmyadmin-3.4":{ "info":{ } }, "jenkins-client-1.4":{ "info":{ } } }, ... In JBDS we had a workaround (while the fix was not available) where we would check for the value of the "info" property. If it was undefined, we went for the creation log (the output provided when the cartridge was embedded) and extracted the URL from it via Regex. Back then the property was empy/undefined: "info": "" The current situation, where the info holds an empty object "info": {} unfortunately is even worse sind it breaks our check and our users wont get any URLs at any Expected results: In https://bugzilla.redhat.com/show_bug.cgi?id=812046 a fix was introduced that would have reported minimal bits about embedded cartridges within the response to the application: "embedded": { "mongodb-2.0": { "database_name": "phpappjenkins", "username": "admin", "info": "Connection URL: mongodb://127.0.253.1:27017/\n", "password": "g1qCdE96waPz", "connection_url": "mongodb://127.0.253.1:27017/" }, "rockmongo-1.1": { "username": "admin", "info": "URL: https://phpappjenkins-domainbill004.dev.rhcloud.com/rockmongo/\n", "password": "g1qCdE96waPz", "connection_url": "https://phpappjenkins-domainbill004.dev.rhcloud.com/rockmongo/" }, This is very handy for a user of the REST service since he does not have to do additional requests to find out about the embedded cartridges. The minimal bits are already available within the response for the application. Additional info:
To be fully precise, in protocol "1.0" the "info" either had some verbose info where we could extract the url or it was undefined/empty: "embedded":{ "mongodb-2.0":{ "info":"Connection URL: mongodb://127.13.83.1:27017/\n" }, "mysql-5.1":{ "info":"Connection URL: mysql://127.13.83.1:3306/\n" } }, or "embedded":{ "haproxy-1.4":{ "info":"" } }, The fix in 812046 is fully backward compatible since it was not removing the "info" element but was adding more structured info that latter clients could rely on, while existing clients would not break.
We're using the following regex to extract the url from "info": URL: (.+)\\n*
Commits pushed to master at https://github.com/openshift/origin-server https://github.com/openshift/origin-server/commit/f9ca877ea2ad264c8b9f9b75af63bbc8ebea0480 Fix for bug 916268 - adding properties for embedded carts in application rest response Note: this was opened as a regression for bug 812046 https://github.com/openshift/origin-server/commit/389e81d0ae09f74da8ab424e9c8852703a909bcb Merge pull request #1478 from abhgupta/abhgupta-dev Fix for bug 916268 - re-adding properties for embedded carts
Note to QE: This was a regression. Please re-verify all test cases around bug 812046 as part of the verification for this bug.
Are we going to store such information in 2 places, afaik, for now it's stored in cartridges link as well, and site and CLI may be using the following link as well: # curl -k -H "Accept: application/json" --user "xtian+t1:1278" https://localhost/broker/rest/domains/domx1/applications/phpapp1/cartridges| "properties": [ { "description": "Root user on mysql database", "name": "username", "type": "cart_data", "value": "adminQp9eTxY" }, { "description": "Password for root user on mysql database", "name": "password", "type": "cart_data", "value": "sCS-2WPhFWHJ" }, { "description": "MySQL DB name", "name": "database_name", "type": "cart_data", "value": "phpapp1" }, { "description": "MySQL DB connection URL", "name": "connection_url", "type": "cart_data", "value": "mysql://127.0.251.129:3306/" }
Afaik the above is only valid for protocol 1.1. JBDS is currently only talking 1.0 where the above is not available.
@Xiaoli: do "curl -H "Accept: application/xml;version=1.0" --user "<USER>:<PASSWORD>" https://openshift.redhat.com/broker/rest/domains/honkabonka2/applications/as/cartridges (notice the ;version=1.0 in the accept-header). You'll see that you dont get the above properties. In this issue we're talking about our existing JBDS users which cannot have their library replaced easily (300K+ users). We have to ensure that they get an URL.
Test this bug on STG curl -H "Accept: application/json;version=1.0" --user "wsun:changeme" https://stg.openshift.redhat.com/broker/rest/domains/bmengstgw/applications/| python -mjson.tool "embedded": { "jenkins-client-1.4": { "info": "Job URL: https://jk1-bmengstgw.stg.rhcloud.com/job/ruby18-build/", "job_url": "https://jk1-bmengstgw.stg.rhcloud.com/job/ruby18-build/" }, "mongodb-2.2": { "connection_url": "mongodb://127.6.121.1:27017/", "database_name": "ruby18", "info": "Connection URL: mongodb://127.6.121.1:27017/", "password": "_E9PFuxbtR3g", "username": "admin" }, "mysql-5.1": { "connection_url": "mysql://127.6.121.1:3306/", "database_name": "ruby18", "info": "Connection URL: mysql://127.6.121.1:3306/", "password": "hlJGD2MXSLtJ", "username": "adminnDvSUmL" }, "phpmyadmin-3.4": { "connection_url": "https://ruby18-bmengstgw.stg.rhcloud.com/phpmyadmin/", "info": "Connection URL: https://ruby18-bmengstgw.stg.rhcloud.com/phpmyadmin/" }, "rockmongo-1.1": { "connection_url": "https://ruby18-bmengstgw.stg.rhcloud.com/rockmongo/", "info": "Connection URL: https://ruby18-bmengstgw.stg.rhcloud.com/rockmongo/" } },
I ran some pretty complete tests against STG and things look very good now, thanks! I saw URLs for * mysql * phpmyadmin * postgres * mongo * rockmongo * jenkins-client Haproxy seems to have no info. I guess that this is correct, right? But there 1 thing that still bothers us unfortunately: Initially the connection URL was only available in the message at creation time and in the environment variables. Having them in "info" was being discussed but not implemented yet. We had to go GA and implemented an approach where we would get the connection URL from the messages when the cartridge was created and tried to get it from "info" later, when there were no creation messages. This worked well until the creation messages changed, they started holding the connection URL twice: "messages":[ { "exit_code":null, "field":null, "severity":"info", "text":"Added mysql-5.1 to application as" }, { "exit_code":0, "field":"result", "severity":"info", "text":"\nMySQL 5.1 database added. Please make note of these credentials:\n\n Root User: <USER>\n Root Password: <PASS>\n Database Name: as\n\nConnection URL: mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT/\n\nYou can manage your new MySQL database by also embedding phpmyadmin-3.4.\nThe phpmyadmin username and password will be the same as the MySQL credentials above.\n" }, { "exit_code":0, "field":"appinfo", "severity":"info", "text":"Connection URL: mysql://127.11.220.3:3306/\n" } ], * Connection URL: mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT * Connection URL: mysql://127.11.220.3:3306/ Unfortunately our regex that extracts the connection URL from the messages will now get the first connection URL. Is it possible to either switch the order of the message-objects in the json or simply use the very same connection string in both?
Andre Dietisheim <adietish> made a comment on jira JBIDE-13631 As commented above, the connection URL is now reported differently, depending on when the URL is requested. * In the "session" when the cartridge was created (mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT): !mysql-url-at-creation.png! * In latter "sessions" (mysql://127.11.220.3:3306/): !mysql-url-after-creation.png! Afaik this is only the case for PostgreSQL and MySQL (not mongoDB).
Andre Dietisheim <adietish> made a comment on jira JBIDE-13631 added integration tests to openshift-java-client in https://github.com/openshift/openshift-java-client/pull/23
Verified on devenv_2904, get 3 kind of db cartridge info [qgong@dhcp-8-169 dev]$ curl -k -X GET -H 'Accept: application/xml' --user qgong:111111 https://ec2-54-234-245-80.compute-1.amazonaws.com/broker/rest/domains/qgong1/applications/ruby18 <?xml version="1.0" encoding="UTF-8"?> <response> <status>ok</status> <type>application</type> <data> <application> <embedded> <mysql-5.1> <connection-url>mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT/</connection-url> <username>adminYJ1DegP</username> <password>_EsKQddub7NV</password> <database-name>ruby18</database-name> <info>Connection URL: mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT/</info> </mysql-5.1> ... [qgong@dhcp-8-169 dev]$ curl -k -X GET -H 'Accept: application/xml' --user qgong:111111 https://ec2-54-234-245-80.compute-1.amazonaws.com/broker/rest/domains/qgong1/applications/python1 <?xml version="1.0" encoding="UTF-8"?> <response> <status>ok</status> <type>application</type> <data> <application> <embedded> <postgresql-8.4> <connection-url>postgresql://$OPENSHIFT_POSTGRESQL_DB_HOST:$OPENSHIFT_POSTGRESQL_DB_PORT/</connection-url> <username>admin</username> <password>aKheUIBz7acu</password> <database-name>python1</database-name> <info>Connection URL: postgresql://$OPENSHIFT_POSTGRESQL_DB_HOST:$OPENSHIFT_POSTGRESQL_DB_PORT/</info> </postgresql-8.4> ... [qgong@dhcp-8-169 dev]$ curl -k -X GET -H 'Accept: application/xml' --user qgong:111111 https://ec2-54-234-245-80.compute-1.amazonaws.com/broker/rest/domains/qgong1/applications/jbossews1 <?xml version="1.0" encoding="UTF-8"?> <response> <status>ok</status> <type>application</type> <data> <application> <embedded> <mongodb-2.2> <connection-url>mongodb://$OPENSHIFT_MONGODB_DB_HOST:$OPENSHIFT_MONGODB_DB_PORT/</connection-url> <username>admin</username> <password>_UuRz5BbKz_1</password> <database-name>jbossews1</database-name> <info>Connection URL: mongodb://$OPENSHIFT_MONGODB_DB_HOST:$OPENSHIFT_MONGODB_DB_PORT/</info> </mongodb-2.2> ...
thanks, this looks awesome!
I verified this today and saw this fixed for NEW applications. The url was reported using env variables as shown above. Nevertheless the picture was slightly different for EXISTING applications: They have an url but it's show using the plain IP address, not the env variables. Is this expected?
For the existing application, it is really show info as IP address in production evn: [qgong@dhcp-10-87 dev]$ curl -k -X GET -H 'Accept: application/xml' --user qgong:****** https://openshift.redhat.com/broker/rest/domains/qgong/applications/redmine <?xml version="1.0" encoding="UTF-8"?> <response> <status>ok</status> <type>application</type> <data> <application> <embedded> <mysql-5.1> <username>admin</username> <database-name>redmine</database-name> <password>Qx6vuG-ZaLKK</password> <connection-url>mysql://127.7.140.1:3306/</connection-url> <info>Connection URL: mysql://127.7.140.1:3306/</info> </mysql-5.1> </embedded> ...
In https://bugzilla.redhat.com/show_bug.cgi?id=923442 we decided to migrate existing users in production.