9bae3b1832
Previously L3 HA generated a bash script and copied it to a per-router configuration directory that was visible to that router's keepalived instance. This patch changes the in-line generated Bash script to a Python script that can be maintained in the repository. The bash script was used as a keepalived notifier script, that was invoked by keepalived whenever a state transition occured. These notifier scripts may be invoked by keepalived out of order in case it transitions quickly twice. For example, if the master failed and two slaves fight for the new master role. One will transition to master, and the other will often transition to master and then immidiately back to standby. In this case, the transition scripts were often fired out of order, resulting in the wrong state being reported. The proposed approach is to get rid of the keepalived notifier scripts entirely. Instead, monitor IP changes on the HA device. If the omnipresent IP address was configured on the HA device, it means that we're looking at a master instance. If it was deleted, the router transition to standby or fault. In order to keep the L3 agent CPU usage down, it will spawn a process per HA router. That process will start the ip address monitor. Whenever it gets an IP address change event, it will notify the L3 agent via a unix domain socket. Partially-Implements: blueprint report-ha-router-master Change-Id: I2022bced330d5f108fbedd40548a901225d7ea1c Closes-Bug: #1402010 Closes-Bug: #1367705 |
||
|---|---|---|
| bin | ||
| doc | ||
| etc | ||
| neutron | ||
| rally-jobs | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .pylintrc | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| TESTING.rst | ||
| babel.cfg | ||
| openstack-common.conf | ||
| 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
-
http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html
- Neutron API Reference:
-
http://docs.openstack.org/api/openstack-network/2.0/content/
- 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.