I also consider this to be a bug. From an operator perspective, hostname will/should be resolved to the IP of the network_interface and not the API interface. In openstack, the API interface (or the internal interface as it is normally called) is an isolated network w/o a gateway. Thus it does not seem correct that the DNS or /etc/hosts resolution should point to the API interface.
As it is today, rabbitmq requires hostnames to work (it does not work with IPs for some reason). Kolla solves this by populating the hosts /etc/hosts file or relies on external DNS. Arguably this is not the correct solution. DNS will most likely point to the network_interface, and populating /etc/hosts might not be working for several reasons. Order in nsswitch.conf matters for once, and depending on operator organization /etc/hosts can be under the control of some other CM system and any changes will be reverted. Another aspect is that on minimalistic OS's, modifying local root fs is not possible. At least not dynamically. Remember that in kolla it should be simple to move/remove/add rabbitmq containers. Thus the solution needed for this is better if it is contained within kolla and not require any external dependencies.
One solution for this could be that the rabbitmq containers generates their own /etc/hosts file in the containers with the API interface IP and some constructed hostname. Remember this is only needed for rabbitmq clustering so it does not really matter what the hostnames are, as long as they are resolvable and points to the right IP/interface.
ex
hostnamames are node-a, node-b, node-c and DNS resolution points to network_interface
in the rabbitmq containers, the /etc/hosts file looks something like below where 10.0.0.0/24 is the api network.
10.0.0.10 node-a-api
10.0.0.11 node-b-api
10.0.0.12 node-c-api
hi all,
I also consider this to be a bug. From an operator perspective, hostname will/should be resolved to the IP of the network_interface and not the API interface. In openstack, the API interface (or the internal interface as it is normally called) is an isolated network w/o a gateway. Thus it does not seem correct that the DNS or /etc/hosts resolution should point to the API interface.
As it is today, rabbitmq requires hostnames to work (it does not work with IPs for some reason). Kolla solves this by populating the hosts /etc/hosts file or relies on external DNS. Arguably this is not the correct solution. DNS will most likely point to the network_interface, and populating /etc/hosts might not be working for several reasons. Order in nsswitch.conf matters for once, and depending on operator organization /etc/hosts can be under the control of some other CM system and any changes will be reverted. Another aspect is that on minimalistic OS's, modifying local root fs is not possible. At least not dynamically. Remember that in kolla it should be simple to move/remove/add rabbitmq containers. Thus the solution needed for this is better if it is contained within kolla and not require any external dependencies.
One solution for this could be that the rabbitmq containers generates their own /etc/hosts file in the containers with the API interface IP and some constructed hostname. Remember this is only needed for rabbitmq clustering so it does not really matter what the hostnames are, as long as they are resolvable and points to the right IP/interface.
ex
hostnamames are node-a, node-b, node-c and DNS resolution points to network_interface
in the rabbitmq containers, the /etc/hosts file looks something like below where 10.0.0.0/24 is the api network.
10.0.0.10 node-a-api
10.0.0.11 node-b-api
10.0.0.12 node-c-api