Because you probably don't get any DNS resolution within your underlying infrastructure, nova is actually using the /etc/hosts file to resolve your host node name.
I'm having the same issue, however, before starting to fix it, I'll need to do some tests and have a few discussion with the team in order to validate that nova is the only service relying on these IPs.
For instance, changing the task to use migration_interface variable instead of the current api_interface MIGHT have an impact on RabbitMQ.
Hi Alexander, just to give you more insight on this one.
This is due to nova-compute (manager.py) calling for this function on cold migration: /opendev. org/openstack/ nova/src/ commit/ f5f7c2540150c7e e7640c834d5caec 31b3f5a7ab/ nova/utils. py#L109
https:/
Because you probably don't get any DNS resolution within your underlying infrastructure, nova is actually using the /etc/hosts file to resolve your host node name.
Which in turn wrongly redirect it using your internal api subnet as the /etc/hosts file being propulated in here using the api_interface value: /opendev. org/openstack/ kolla-ansible/ src/commit/ e744b9d510ba183 d5a80b3e467d0e7 64eb5c9e02/ ansible/ roles/baremetal /tasks/ pre-install. yml#L25
https:/
I'm having the same issue, however, before starting to fix it, I'll need to do some tests and have a few discussion with the team in order to validate that nova is the only service relying on these IPs.
For instance, changing the task to use migration_interface variable instead of the current api_interface MIGHT have an impact on RabbitMQ.