Bug 1193886

Summary: RFE: wait for DB after boot
Product: [Community] RDO Reporter: Miroslav Suchý <msuchy>
Component: RFEsAssignee: hguemar
Status: CLOSED EOL QA Contact: Shai Revivo <srevivo>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: IcehouseCC: apevec, chris.brown, karlthered, markmc, srevivo
Target Milestone: ---   
Target Release: trunk   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-18 06:09:50 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 Miroslav Suchý 2015-02-18 13:52:02 UTC 
Description of problem:
Just after reboot of controller I see in /var/log/messages lots of errors where openstack service are unable to connect to DB. E.g.:
Feb 18 13:27:10 fed-cloud09 cinder-volume: 2015-02-18 13:27:10.941 4396 TRACE cinder.openstack.common.threadgroup OperationalError: (OperationalError) (2013, "Lost connection to MySQL server at 'reading initial communication packet', system error: 104") None None

Several moment later it is successfully connected and it works fine. So it is just about getting rid of this errors in log and postpone starting little bit.

This is probably distribution only related, so I am filing it here and not in upstream.

I understand that we could not depend on db.service directly, because it can be on different machine.

I would suggest to create service openstack-wait-for-db.service, which would all other (e.g. openstack-cinder-api.service) have listed in "After".
This service would just check if MARIADB_HOST point to different host (and then exit immediately) or if it point to this machine and then wait till mariadb service is available. 


Version-Release number of selected component (if applicable):
happened to me on RDO Icehouse
Comment 1 Haïkel Guémar 2016-01-17 16:11:43 UTC 
Makes sense, targeted to Mitaka and possibly backported to Liberty.
Comment 2 Alan Pevec 2016-02-01 15:22:19 UTC 
Why not just do not log TRACE if that's too verbose? oslo-db library will try reconnecting and success once database is available.
Comment 4 Christopher Brown 2017-06-17 19:09:31 UTC 
I think this is stale and can be closed?