manager.py dropdb is stuck

[Dmitriy Kruglov]

Rebuild the db is not possible because the process is stuck on dbopdb stage

Step to reproduce:
1) enter to docker nailgun container
2) manage.py dropdb && manage.py syncdb && manage.py loaddefault

The workaround is restart postgres and/or nailgun container.

ISO info:
VERSION:
  feature_groups:
    - mirantis
  production: "docker"
  release: "7.0"
  openstack_version: "2015.1.0-7.0"
  api: "1.0"
  build_number: "150"
  build_id: "2015-08-09_09-17-24"
  nailgun_sha: "58c080206cc17137b124744a40218c89beb6bb28"
  python-fuelclient_sha: "e069d9fde92451ec7f555342951807c5528e96e5"
  fuel-agent_sha: "57145b1d8804389304cd04322ba0fb3dc9d30327"
  fuel-nailgun-agent_sha: "e01693992d7a0304d926b922b43f3b747c35964c"
  astute_sha: "e1d3a435e5df5b40cbfb1a3acf80b4176d15a2dc"
  fuel-library_sha: "1851b4dff75170dbd63f6e15cde734e348e86d27"
  fuel-ostf_sha: "c7f745431aa3c147f2491c865e029e0ffea91c47"
  fuelmain_sha: "bdca75d0256338519c7eddd8a840ee6ecba7f992"

[Ivan Ponomarev (ivanzipfer)]

This is a db sync problem.
I think this happen when previous transaction is not closed.
The workaround is restart postgres or nailgun container.

[Evgeniy L (rustyrobot)]

Workaround is to stop statssenderd, since it's doesn't affect deployment and has workaround, lower the priority to High, because I've seen many times that people have problem with that.

[Ihor Kalnytskyi (ikalnytskyi)]

It's not a workaround, it's the only right solution. We can't drop db schema if some other process uses it. The only right choice here is to make:

  $ supervisorctl stop all
  $ manage.py dropdb && manage.py syncdb && manage.py loaddefault
  $ supervisorctl start all

Move it to Invalid, since there's nothing that should be fixed.