Bug 1025249 - Should remove the gear-registry.db.lock for haproxy cartridge after migration
Summary: Should remove the gear-registry.db.lock for haproxy cartridge after migration
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Online
Classification: Red Hat
Component: Containers
Version: 2.x
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Andy Goldstein
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-31 10:17 UTC by Meng Bo
Modified: 2015-05-14 23:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-04 17:28:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Meng Bo 2013-10-31 10:17:32 UTC
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:
always

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 17:21:04 UTC
https://github.com/openshift/li/pull/2084

Comment 2 Andy Goldstein 2013-11-04 17:28:10 UTC
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-06 02:16:27 UTC
@agoldste

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"

Thanks

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


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