© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hello Miro,
I reproduced this problem and checked the ovn-northd, and here is what I have found, supposing we are creating a VM with IP address 192.168.10.25.
1. If ovn-northd has one residual port with the same IP address (192.168.10.25), but this IP is still available in neutron, then this port will fail.
2. Then I write a script to clean the residual port and then recreate it using the same IP, then this port can be created successfully.
So the inconsistency between neutron and ovn-northd caused this problem. Creating a batch of ports will cause some pressure on ovn-northd since this might require more resources than a single port. I guess in our case, the leader election might cause this problem. We are using a 3-node cluster (node-1, node-2 and node-3), suppose now the leader is node-1, because of the batching pressure, then the main node has switched to node-2 due to slow response. Perhaps node-1 has received the request but handling it slowly, then this port has left in ovn-northd.
Regards.