Hi,
A few days ago, we made two big changes on our production infrastructure: we
updated to latest Ocata and we changed the outgoing port on our network node to
a lacp port. We made the change by switching the port in br-ex in openvswitch
to the new lacp-backed port. Ever since these two things happened right after
the other, we’ve ran into two issues, one which has much worse consequences
than the other:
1.We can’t add floating ips to instances anymore. The interface says the
operation completed successfully, the database gets updated, but the IP address
doesn’t exist in the network namespace on the network nodes. Strangely enough,
the iptables rules in the NAT table do exist. The port just doesn’t receive the
new address. Adding the floating ip address manually to the virtual interface
with "ip netns exec *qrouter namespace id* ip addr add *ip address* dev
*virtual interface*" solves this, but is in no way a permanent solution.
2.We’re getting an error message in the L3-agent whenever it starts informing
us it was unable to add some rules in iptables because there’s a lock on
xtables, while as far as we know, the L3-agent itself is the one holding the
lock. Here’s the error:
2017-09-18 13:00:55.426 18575 ERROR neutron.callbacks.manager # Generated by
iptables_manager
2017-09-18 13:00:55.426 18575 ERROR neutron.callbacks.manager *nat
2017-09-18 13:00:55.426 18575 ERROR neutron.callbacks.manager -I
neutron-l3-agent-PREROUTING 7 -d 169.254.169.254/32 -i qr-+ -p tcp -m tcp
--dport 80 -j REDIRECT --to-ports 9697
2017-09-18 13:00:55.426 18575 ERROR neutron.callbacks.manager COMMIT
2017-09-18 13:00:55.426 18575 ERROR neutron.callbacks.manager # Completed by
iptables_manager
2017-09-18 13:00:55.426 18575 ERROR neutron.callbacks.manager ; Stdout: ;
Stderr: Another app is currently holding the xtables lock. Perhaps you want to
use the -w option?
2017-09-18 13:00:55.426 18575 ERROR neutron.callbacks.manager
2017-09-18 13:00:55.426 18575 ERROR neutron.callbacks.manager
It’s not clear exactly how this is affecting the setup, as metadata is still
going through properly (most likely through the DHCP) but it’s quite worrying.
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
