Bug 1025249 - Should remove the gear-registry.db.lock for haproxy cartridge after migration
Should remove the gear-registry.db.lock for haproxy cartridge after migration
Product: OpenShift Online
Classification: Red Hat
Component: Containers (Show other bugs)
Unspecified Unspecified
medium Severity low
: ---
: ---
Assigned To: Andy Goldstein
libra bugs
Depends On:
  Show dependency treegraph
Reported: 2013-10-31 06:17 EDT by Meng Bo
Modified: 2015-05-14 19:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-04 12:28:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Meng Bo 2013-10-31 06:17:32 EDT
Description of problem:
Create scalable app on stage ami, do server upgrade and gear migrate, check the haproxy cartridge dir in the scalable app. The gear-registry.db has been moved to gear home dir, but the lock file is still there.

Version-Release number of selected component (if applicable):
devenv-stage_528 to devenv_3973

How reproducible:

Steps to Reproduce:
1.Create scalable apps on devenv-stage_528
2.Upgrade the server to devenv_3973
3.Restart broker, mcollective, clean broker cache and pending ops
4.Migrate the datastore
rhc-admin-migrate-datastore --version 2.0.35 --compatible
5.Migrate the gears
oo-admin-upgrade upgrade-node --version 2.0.35 --ignore-cartridge-version
6.Check the haproxy cartridge dir for scalable apps

Actual results:
The gear-registry.db.lock is still there.

Expected results:
The lock file should be removed since the gear-registry.db has been moved.

Additional info:
[jbeap2s-bmengmdev.dev.rhcloud.com conf]\> ls
gear-registry.db.lock  haproxy.cfg  haproxy.cfg.lock
Comment 1 Andy Goldstein 2013-11-04 12:21:04 EST
Comment 2 Andy Goldstein 2013-11-04 12:28:10 EST
After talking to Dan McPherson, we decided to close this as not a bug. It would have been nice to remove the lock file during this upgrade, but given the timing, it's a change we aren't comfortable doing right now. Apps created previously will continue to have this file, but it's harmless.
Comment 3 Meng Bo 2013-11-05 21:16:27 EST

Do you think it is better to close this as WON'T FIX instead? Since you also thought it is "nice to remove but harmless"

Comment 4 Andy Goldstein 2013-11-06 09:30:40 EST
Yes, that makes more sense - thanks!

Note You need to log in before you can comment on or make changes to this bug.