Description of problem: Set up an environment with 2 nodes and move a gear. On move the initial deployment directory is created and it not used since the previous deployment is rsync'd from the old gear. During the move process an attempt is made to register the deployment but it fails with a 422 unprocessable intity since the metadata is nil. A side-effect of a recent upstream change allows for this 422 to be ignored and the move to still be considered successful. I suspect there may be gears with bogus deployment directories dangling. There may also be excess 422s in the Broker logs.
Here's one approach for dealing with this: https://github.com/openshift/origin-server/pull/4616
*** Bug 1057976 has been marked as a duplicate of this bug. ***
Checked on devenv_4348, before and after move gear, the deployment dir is the same. [root@ip-10-239-28-10 52f5cfa081c9849092000027]# ls app-deployments/ 2014-02-08_01-33-10.039 by-id current [root@domU-12-31-39-04-70-20 52f5cfa081c9849092000027]# ls app-deployments/ 2014-02-08_01-33-10.039 by-id current And for bug 1057976, the app can be restored successfully after move. [root@domU-12-31-39-04-70-20 ~]# rhc snapshot restore ruby19 Restoring from snapshot ruby19.tar.gz... Removing old git repo: ~/git/ruby19.git/ Removing old data dir: ~/app-root/data/* Restoring ~/git/ruby19.git and ~/app-root/data Activation status: success RESULT: Success move bug to verified.