| 2021-08-23 16:53:16 |
Pedro Guimarães |
description |
Hi,
Full juju status: https://pastebin.canonical.com/p/DP96fkRz9y/
I am currently running a mysql/keystone/horizon/vault deployment to provide ldap connection on top of a private cloud.
I am using fan-networking for this deployment.
Mysql runs on top of LXCs whereas keystone / vault / horizon may run on top of lxcs or directly on VMs. However, units running on VMs directly cannot connect to the mysql cluster running on top of LXC + FAN net.
These routers get stuck in:
keystone-mysql-router/1 waiting - (config-changed) MySQL Router not yet bootstrapped
With following flags are present in the unit above:
charm.installed
charm.is-subordinate
charm.mysqlrouter.bootstrap-attempted <<<<<<---------
charms.openstack.do-default-charm.installed
charms.openstack.do-default-config.changed
charms.openstack.do-default-update-status
charms.openstack.do-default-upgrade-charm
db-router.available
db-router.connected
endpoint.shared-db.changed
endpoint.shared-db.changed.egress-subnets
endpoint.shared-db.changed.ingress-address
endpoint.shared-db.changed.private-address
endpoint.shared-db.joined
keystone-mysql-router-installed
shared-db.available
Looking into mysql router code, this is the line it gets stuck:
https://github.com/openstack/charm-mysql-router/blob/master/src/lib/charm/openstack/mysql_router.py#L411-L466
And indeed, the cmd generated above uses a fan-networking IP:
sudo /usr/bin/mysqlrouter --user mysql --name keystone-mysql-router --bootstrap mysqlrouteruser:<PASSWORD>@252.153.13.224 --directory /var/lib/mysql/keystone-mysql-router --conf-use-sockets --conf-bind-address 127.0.0.1 --report-host <HOST_IP> --conf-base-port 3306 --disable-rest --force
full command + output:
https://pastebin.canonical.com/p/z6B27qpF8v/
Whereas the relation between mysql cluster and that same unit shows:
https://pastebin.canonical.com/p/ftzFsfrvjp/
Which shows ingress-address seen by mysql-innodb-cluster is actually the host's IP and not fan-networking IP.
That actually exposes another issue, in which mysql-innodb-cluster cannot be used outside of Juju relations given there is no way to manually edit the access list.
Mysql cluster charm should expose an option to add subnets to this access list, e.g.:
$ juju config mysql-innodb-cluster access-list="252.0.0.0/8,10.0.0.0/16" |
Hi,
Full juju status: https://pastebin.canonical.com/p/DP96fkRz9y/
Bundle: https://pastebin.canonical.com/p/2cvJcqxS6p/
I am currently running a mysql/keystone/horizon/vault deployment to provide ldap connection on top of a private cloud.
I am using fan-networking for this deployment.
Mysql runs on top of LXCs whereas keystone / vault / horizon may run on top of lxcs or directly on VMs. However, units running on VMs directly cannot connect to the mysql cluster running on top of LXC + FAN net.
These routers get stuck in:
keystone-mysql-router/1 waiting - (config-changed) MySQL Router not yet bootstrapped
With following flags are present in the unit above:
charm.installed
charm.is-subordinate
charm.mysqlrouter.bootstrap-attempted <<<<<<---------
charms.openstack.do-default-charm.installed
charms.openstack.do-default-config.changed
charms.openstack.do-default-update-status
charms.openstack.do-default-upgrade-charm
db-router.available
db-router.connected
endpoint.shared-db.changed
endpoint.shared-db.changed.egress-subnets
endpoint.shared-db.changed.ingress-address
endpoint.shared-db.changed.private-address
endpoint.shared-db.joined
keystone-mysql-router-installed
shared-db.available
Looking into mysql router code, this is the line it gets stuck:
https://github.com/openstack/charm-mysql-router/blob/master/src/lib/charm/openstack/mysql_router.py#L411-L466
And indeed, the cmd generated above uses a fan-networking IP:
sudo /usr/bin/mysqlrouter --user mysql --name keystone-mysql-router --bootstrap mysqlrouteruser:<PASSWORD>@252.153.13.224 --directory /var/lib/mysql/keystone-mysql-router --conf-use-sockets --conf-bind-address 127.0.0.1 --report-host <HOST_IP> --conf-base-port 3306 --disable-rest --force
full command + output:
https://pastebin.canonical.com/p/z6B27qpF8v/
Whereas the relation between mysql cluster and that same unit shows:
https://pastebin.canonical.com/p/ftzFsfrvjp/
Which shows ingress-address seen by mysql-innodb-cluster is actually the host's IP and not fan-networking IP.
That actually exposes another issue, in which mysql-innodb-cluster cannot be used outside of Juju relations given there is no way to manually edit the access list.
Mysql cluster charm should expose an option to add subnets to this access list, e.g.:
$ juju config mysql-innodb-cluster access-list="252.0.0.0/8,10.0.0.0/16" |
|
