Created attachment 612358 [details] development.log Description of problem: After move, I found the mongodb process isn't up, so can't connect success. Version-Release number of selected component (if applicable): devenv_21 How reproducible: always Steps to Reproduce: 1.Create multile node env, create 2 districts and add node to them. 2.Create scalable app like(python,jboss, php),then embemd mongodb to this app. 3.Them move the mongodb gear accross district rhc-admin-move --gear_uuid db7d9a70280e4aa9b8c68f1a9a65f084 -i ip-10-122-51-2 --allow_change_district Actual results: ssh into this app [qsphp-qgong2.dev.rhcloud.com ~]\> mongo MongoDB shell version: 2.0.7 connecting to: 318065ca46-qgong2.dev.rhcloud.com:38096/admin Thu Sep 13 02:41:07 DBClientCursor::init call() failed Thu Sep 13 02:41:07 Error: Error during mongo startup. :: caused by :: DBClientBase::findN: transport error: 318065ca46-qgong2.dev.rhcloud.com:38096 query: { whatsmyuri: 1 } shell/mongo.js:86 exception: connect failed Expected results: could connect mongodb success. Additional info: all other db like mysql and postgresql work well.
Same error for non_scalabel app has been fixed by https://bugzilla.redhat.com/show_bug.cgi?id=855825
Fixed. Pull request https://github.com/openshift/crankcase/pull/484
Created attachment 612706 [details] newest developement.log
Still reproduced on devenv_2176, this build has merged your pull, after move: [qsphp-qgong4.dev.rhcloud.com ~]\> mongo MongoDB shell version: 2.0.7 connecting to: 81684aa525-qgong4.dev.rhcloud.com:38051/admin Thu Sep 13 22:25:07 DBClientCursor::init call() failed Thu Sep 13 22:25:07 Error: Error during mongo startup. :: caused by :: DBClientBase::findN: transport error: 81684aa525-qgong4.dev.rhcloud.com:38051 query: { whatsmyuri: 1 } shell/mongo.js:86 exception: connect failed use mongodb user also can't log in server anymore(and I have waited some mins for DNS finish) [qgong@localhost dev]$ ssh 81684aa5257b439e82b27ffc3fc9e772.rhcloud.com Warning: Permanently added '81684aa525-qgong4.dev.rhcloud.com,184.72.66.10' (RSA) to the list of known hosts. Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Yeah it was a bad fix. New (tested) fix is in with pull request - https://github.com/openshift/crankcase/pull/488 The mongodb user not being able to log in is a separate bug. It possibly exists with mysql also.
After move, can't find the process for the mongdb user in destination instance. [root@ip-10-90-249-240 stickshift]# ps -ef|grep 1003 root 18136 1369 0 22:08 pts/1 00:00:00 grep 1003
How is ps -ef| grep 1003 suggesting the mongo process? If '1003' means uid, then uid can (and most likely would) change after move across districts. How to find out if mongo is still running/reachable? Connect to the web/haproxy gear and connect through OPENSHIFT_*DB_HOST/PORT.
(In reply to comment #7) > How is ps -ef| grep 1003 suggesting the mongo process? > If '1003' means uid, then uid can (and most likely would) change after move > across districts. > > How to find out if mongo is still running/reachable? Connect to the > web/haproxy gear and connect through OPENSHIFT_*DB_HOST/PORT. the 1003 is the already changed userid after move. yes, we can Connect to the web/haproxy gear and connect through OPENSHIFT_*DB_HOST/PORT. type "mongo"
This issue fixed by this pull: https://github.com/openshift/crankcase/pull/488
verified on devenv_2179