a2bd0b4b53
With Xenial (and maybe older versions), the modified timestamps in /sys/class/net/(device_name) are not stable. They appear to work for a period of time, and then when some kind of cache clears on the kernel side, all of the timestamps are reset to the latest access time. This was causing the Linux Bridge agent to think that the interfaces were experiencing local changes much more frequently than they actually were, resulting in more polling to the Neutron server and subsequently more BUILD->ACTIVE->BUILD->ACTIVE transitions in the logical model. The purpose of the timestamp patch was to catch rapid server REBUILD operations where the interface would be deleted and re-added within a polling interval. Without it, these would be stuck in the BUILD state since the agent wouldn't realize it needed to wire the ports. This patch switches to looking at the IFINDEX of the interfaces to use as a sort of logical timestamp. If an interface gets removed and readded, it will get a different index, so the original timestamp comparison logic will still work. In the future, the agent should undergo a larger refactor to just watch 'ip monitor' for netlink events to replace the polling of the interface listing and the timestamp logic entirely. However, this approach was taken due to the near term release and the ability to back-port it to older releases. This was verified with both Nova rebuild actions and Nova interface attach/detach actions. Change-Id: I016019885446bff6806268ab49cd5476d93ec61f Closes-Bug: #1622833 |
||
---|---|---|
api-ref | ||
bin | ||
devstack | ||
doc | ||
etc | ||
neutron | ||
rally-jobs | ||
releasenotes | ||
tools | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.pylintrc | ||
.testr.conf | ||
CONTRIBUTING.rst | ||
HACKING.rst | ||
LICENSE | ||
MANIFEST.in | ||
README.rst | ||
TESTING.rst | ||
babel.cfg | ||
requirements.txt | ||
run_tests.sh | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
README.rst
Welcome!
You have come across a cloud computing network fabric controller. It has identified itself as "Neutron." It aims to tame your (cloud) networking!
External Resources:
The homepage for Neutron is: http://launchpad.net/neutron. Use this site for asking for help, and filing bugs. Code is available on git.openstack.org at <http://git.openstack.org/cgit/openstack/neutron>.
The latest and most in-depth documentation on how to use Neutron is available at: <http://docs.openstack.org>. This includes:
- Neutron Administrator Guide
- Neutron Developer Guide
- Networking Guide
- Neutron API Reference:
- Current Neutron developer documentation is available at:
For help on usage and hacking of Neutron, please send mail to <mailto:openstack-dev@lists.openstack.org>.
For information on how to contribute to Neutron, please see the contents of the CONTRIBUTING.rst file.