Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1193886 - RFE: wait for DB after boot
Summary: RFE: wait for DB after boot
Keywords:
Status: CLOSED EOL
Alias: None
Product: RDO
Classification: Community
Component: RFEs
Version: Icehouse
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: trunk
Assignee: hguemar
QA Contact: Shai Revivo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-18 13:52 UTC by Miroslav Suchý
Modified: 2017-06-18 06:09 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-18 06:09:50 UTC


Attachments (Terms of Use)

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?


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