Bug 1025249

Summary:	Should remove the gear-registry.db.lock for haproxy cartridge after migration
Product:	OpenShift Online	Reporter:	Meng Bo <bmeng>
Component:	Containers	Assignee:	Andy Goldstein <agoldste>
Status:	CLOSED WONTFIX	QA Contact:	libra bugs <libra-bugs>
Severity:	low	Docs Contact:
Priority:	medium
Version:	2.x	CC:	agoldste
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-04 17:28:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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!