The lxd profile is changed to add eth1 but then both (eth0 + eth1) will get IPs. And sometimes (randomly) juju will get the address from the interface that does not have the default gateway, so charms will expect connection from one of the ips (the one listed on the machines list) but the actual connection goes out with the other ip and is denied, breaking the deployment.
One such example is mysql-innodb-cluster that often gets the error:
Failed configuring instance 10.0.8.168: Cannot set LC_ALL to locale en_US.UTF-8: No such file or directory
Traceback (most recent call last):
File "<string>", line 1, in <module>
mysqlsh.DBError: MySQL Error (1130): Dba.configure_instance: Host '10.0.8.155' is not allowed to connect to this MySQL server
just because it got the ip from the wrong interface. Another case is that neutron-gateway will take eth1 for provider-network but half the times the IP being used by juju is that one so juju agent is lost after neutron-gateway charm completes deployment.
I would suggest turning off dhcp for the second interface using cloud-init on the profile:
The lxd profile is changed to add eth1 but then both (eth0 + eth1) will get IPs. And sometimes (randomly) juju will get the address from the interface that does not have the default gateway, so charms will expect connection from one of the ips (the one listed on the machines list) but the actual connection goes out with the other ip and is denied, breaking the deployment.
One such example is mysql-innodb-cluster that often gets the error:
just because it got the ip from the wrong interface. Another case is that neutron-gateway will take eth1 for provider-network but half the times the IP being used by juju is that one so juju agent is lost after neutron-gateway charm completes deployment.
I would suggest turning off dhcp for the second interface using cloud-init on the profile: