0267c6a5ac
Currently neutron DCHP scheduler assumes that that every server running a dhcp-agent can reach every network. Typically the scheduler can wrongly schedule a vlan network on a dhcp-agent that has no reachability to the network it's supposed to serve (ex: network's physical_network not supported). Typically such usecase can append if: * physical_networks are dedicated to a specific service and we don't want to mix dnsmasqs related to different services (for isolation/configuration purpose), * physical_networks are dedicated to a specific rack (see example diagram http://i.imgur.com/NTBxRxk.png), the rack interconnection can be handled outside of neutron or inside when routed-networks will be supported. This change makes the DHCP scheduler network reachability aware by querying plugin's filter_hosts_with_network_access method. This change provides an implementation for ML2 plugin delegating host filtering to its mechanism drivers: it aggregates the filtering done by each mechanism or disables filtering if any mechanism doesn't overload default mechanism implementation[1] (for backward compatibility with out-of-tree mechanisms). Every in-tree mechanism overloads the default implementation: OVS/LB/SRIOV mechanisms use their agent mapping to filter hosts, l2pop/test/logger ones return empty set (they provide to "L2 capability"). This change provides a default implementation[2] for other plugins filtering nothing (for backward compatibility), they can overload it to provide their own implementation. Such host filtering has some limitations if a dhcp-agent is on a host handled by multiple l2 mechanisms with one mechanism claiming network reachability but not the one handling dhcp-agent ports. Indeed the host is able to reach the network but not dhcp-agent ports! Such limitation will be handled in a follow-up change using host+vif_type filtering. [1] neutron.plugin.ml2.driver_api.MechanismDriver.\ filter_hosts_with_network_access [2] neutron.db.agents_db.AgentDbMixin.filter_hosts_with_network_access Closes-Bug: #1478100 Co-Authored-By: Cedric Brandily <zzelle@gmail.com> Change-Id: I0501d47404c8adbec4bccb84ac5980e045da68b3 |
||
|---|---|---|
| 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.