WARNING: For production deployments on Focal with mysql-innodb-cluster related to vault's certificates do NOT upgrade mysql-router to 8.0.23-0ubuntu0.20.04.1 [0] until we have a charm fix in place.
OK, this is a bad news good news situation.
The good news is that mysql-router now does what every other mysql client (mysql, mysqlsh) does and TLS encrypts communication to mysql by default. So once we are finished we will have a simpler more complete TLS story for mysql.
The bad news is this breaks our current topology for deployments. By simply not relating mysql-innodb-cluster to vault we get TLS for free. The difficulty is for upgrades. The charms will need to learn to unset ssl_ca on their respective relations.
The really bad news is that any production deployments on Focal with mysql-router and TLS enabled (mysql-innodb-cluster related to vault's certificates relation) will break if mysql-router is updated to 8.0.23-0ubuntu0.20.04.1 [0]. Please avoid doing this if at all possible.
If the worst case scenario has occurred, and mysql-router has been upgraded to 8.0.23-0ubuntu0.20.04.1 communication to the database from python clients will fail.
# We need to force mysql-innodb-cluster to re-write its config so change any value in the mysqld.conf. i.e max-connections ++
juju config mysql-innnodb-cluster max-connections=601
# For every db-router relation ID we need to unset ssl_ca
for relid in $(juju run --unit mysql-innodb-cluster/leader -- "relation-ids db-router"); do
juju run --unit mysql-innodb-cluster/leader -- "relation-set $relid ssl_ca="
done
# For every instance of mysql-router we need to unset ssl_ca. i.e. keystone-mysql-router, cinder-mysql-router etc
for relid in $(juju run --unit mysql-router/0 -- "relation-ids shared-db"); do
juju run --unit mysql-router/0 -- "relation-set $relid ssl_ca="
done
We will begin working on an upgrade path for the mysql-router and mysql-innodb-cluster charms
WARNING: For production deployments on Focal with mysql-innodb- cluster related to vault's certificates do NOT upgrade mysql-router to 8.0.23- 0ubuntu0. 20.04.1 [0] until we have a charm fix in place.
OK, this is a bad news good news situation.
The good news is that mysql-router now does what every other mysql client (mysql, mysqlsh) does and TLS encrypts communication to mysql by default. So once we are finished we will have a simpler more complete TLS story for mysql.
The bad news is this breaks our current topology for deployments. By simply not relating mysql-innodb- cluster to vault we get TLS for free. The difficulty is for upgrades. The charms will need to learn to unset ssl_ca on their respective relations.
The really bad news is that any production deployments on Focal with mysql-router and TLS enabled (mysql- innodb- cluster related to vault's certificates relation) will break if mysql-router is updated to 8.0.23- 0ubuntu0. 20.04.1 [0]. Please avoid doing this if at all possible.
If the worst case scenario has occurred, and mysql-router has been upgraded to 8.0.23- 0ubuntu0. 20.04.1 communication to the database from python clients will fail.
The tedious work around is as follows:
juju remove-relation mysql-innodb- cluster: certificates vault:certificates
# We need to force mysql-innodb- cluster to re-write its config so change any value in the mysqld.conf. i.e max-connections ++ cluster max-connections=601
juju config mysql-innnodb-
# For every db-router relation ID we need to unset ssl_ca cluster/ leader -- "relation-ids db-router"); do cluster/ leader -- "relation-set $relid ssl_ca="
for relid in $(juju run --unit mysql-innodb-
juju run --unit mysql-innodb-
done
# For every instance of mysql-router we need to unset ssl_ca. i.e. keystone- mysql-router, cinder-mysql-router etc
for relid in $(juju run --unit mysql-router/0 -- "relation-ids shared-db"); do
juju run --unit mysql-router/0 -- "relation-set $relid ssl_ca="
done
We will begin working on an upgrade path for the mysql-router and mysql-innodb- cluster charms
[0] https:/ /launchpad. net/ubuntu/ +source/ mysql-8. 0/8.0.23- 0ubuntu0. 20.04.1