f0bdb798fa
Today DVR routers are created after a dvr service port is
seen on a given node. But in the case of instance live
migration, the creation of l3 routed networks on the
destination node is delayed since we react to the event.
This patch tries to proactively create routers on the
destination node based on the portbinding profile info
updated by the nova when the instance is on a pre-migration
state.
Nova calls setup_network_on_host during the pre-migration
phase and we update the portbinding profile dict with
an attribute 'migrating_to' as shown below
port:{'binding:profile':{'migrating_to': 'host'}}
where 'host' points to the 'destination' of the port.
L3 plugin will verify the migration profile for the port on
any port update and then take action to create routers in the
respective agents if routers have not been created.
If the live migration fails or if reverted, then the port
binding profile attribute 'migrating_to' will be cleared from
the port profile. In this case, the router and the fip namespace
may be created on the destination node, but since the VM did
not land on the destination node, it would not cause any issues,
since the traffic will still be flowing out from the origination
node, except for the existence of the router and fip namespace.
For some reason if the creation of the router namespace and fip
namespace fails, then the live migration may still proceed as
it is now and the agent will create the router namespace and fip
namespace reactively.
The case were we report status back to Nova and Nova reacting
to the setup_networks_on_host status will be handled in the
upcoming release.
This patch should not affect any upgrades with respect to the
agent or server.
Change-Id: Ibb62f012333cfdfd468bafdc0b4501aa46b4b54d
Related-Bug: #1456073
|
||
|---|---|---|
| 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 | ||
| 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
- Networking Guide
- 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.