And mysql is configured with 180 seconds timeout (apparently FCE templates are using this 180 value):
From /etc/mysql/percona-xtradb-cluster.conf.d/mysqld.cnf:
# Seconds before clearing idle connections
wait_timeout = 180
$ juju config mysql wait-timeout
180
Due to this discrepancy I see the following message happening in /var/log/designate/designate-mdns.log:
2019-02-25 15:26:43.058 141152 ERROR oslo_db.sqlalchemy.engines DBConnectionError: (pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during query') [SQL: u'SELECT 1']
Increasing mysql wait-timeout to 3600 doesn't seem really a good idea (maybe will add memory impact to mysql due to long lasting connections), and there isn't a charm option in designate charm to change idle_timeout to 3600.
This bug affects a project where all timeouts are commented out in designate units:
# grep timeout designate.conf
#tcp_recv_timeout = 0.5
#poll_timeout = 30
#idle_timeout = 3600
#timeout = 30
#idle_timeout = 3600
And mysql is configured with 180 seconds timeout (apparently FCE templates are using this 180 value):
From /etc/mysql/ percona- xtradb- cluster. conf.d/ mysqld. cnf:
# Seconds before clearing idle connections
wait_timeout = 180
$ juju config mysql wait-timeout
180
Due to this discrepancy I see the following message happening in /var/log/ designate/ designate- mdns.log:
2019-02-25 15:26:43.058 141152 ERROR oslo_db. sqlalchemy. engines DBConnectionError: (pymysql. err.Operational Error) (2013, 'Lost connection to MySQL server during query') [SQL: u'SELECT 1']
Increasing mysql wait-timeout to 3600 doesn't seem really a good idea (maybe will add memory impact to mysql due to long lasting connections), and there isn't a charm option in designate charm to change idle_timeout to 3600.