Oslo config generator was introduced in patch [1] to
automatically generate the sample Neutron core configuration
files.
This patch removes the static example configuration files from
the repository as they are now redundant.
[1] https://review.openstack.org/#/c/204206/
DocImpact
Change-Id: Ic7ae2e038b5bd7b215c65c9c565bfe31ef551520
Partially-Implements: blueprint autogen-neutron-conf-file
Closes-bug: #1199963
Depends-On: Ic37a16b6cf8eb92030649f1fc8b198738a8cc104
L3-agent router_id option has been defined in order to associate a
l3-agent to a specific router when use_namespaces=False. The option
use_namespaces has been removed in Mitaka, so router_id option is no
longer needed and can be deprecated in order to prepare its removal in N
cycle.
Closes-Bug: #1518776
Change-Id: Id79499ccbf3ea69ca4cd7e4b2f812f6dbc0406e0
The use_namespaces option has been defined as a workaround to kernels
not properly supporting namespaces. This limitation is behind us, it's
time to remove use_namespaces after its deprecation in Kilo in order to
simplify code and remove a poorly tested case (use_namespaces=False).
This change prepares for removal pullup_route method[1] which was only
used when use_namespaces=False.
[1] neutron.agent.linux.ip_lib
DocImpact
UpgradeImpact
Closes-Bug: #1508188
Related-Bug: #1435382
Depends-On: I303038eec560a6d99421140c2822aed8b518470b
Depends-On: I4feb2a15c7e1e4bfdbed2531b18b8e7d798ab3cc
Change-Id: I2fbf65df1250d9f9f1656b3964ee3b6de1ef1118
dhcp/router_delete_namespaces[1] options have been defined as a
workaround to an iproute2 limitation[1] corrected 2 years ago.
That's why the change removes these options after their deprecation
in Liberty.
[1] in neutron.agent.dhcp/l3.config
DocImpact
Closes-Bug: #1508189
Related-Bug: #1418079
Change-Id: I2a879213c3b095a007a4531f430a33cea9fdf1bd
Changed the interface_driver configure for agents from class
imports to stevedor aliases. The loading method needed to be
updated to load as a DriverManager. Backward compatability
for configuration as class import.
DocImpact
Change-Id: Ic349691989484286cd7c60eaf3ad1454c5852d1f
Closes-Bug: #1504536
This option provides another way to attach to a specific bridge
that is not quite equivalent with how bridge_mappings work in the
L2 agent. This creates inconsistencies between how the L3 agent
behaves when configured with a bridge_mapping and provider properties
of the Neutron network vs. when it just ignores all L2 stuff and
plugs itself directly into the bridge.
See the bug report for more info.
Change-Id: I37de3cd6eaaf34856fa72753f471f4f0a9381836
Closes-Bug: #1491668
This patch adds the common framework to be used by specific
implementations of the DHCPv6 protocol for Prefix Delegation.
It also includes a reference implementation based on the Dibbler
DHCPv6 client. Dibbler version 1.0.1 or greater is required.
Sanity tests are included to verify the installed version.
A patch for admin/user documentation is up for review here:
https://review.openstack.org/#/c/178739
Video guides for configuring and using this feature are available on
YouTube:
https://www.youtube.com/watch?v=wI830s881HQhttps://www.youtube.com/watch?v=zfsFyS01Fn0
Co-Authored-By: Baodong (Robert) Li <baoli@cisco.com>
Co-Authored-By: Sam Betts <sam@code-smash.net>
Change-Id: Id94acbbe96c717f68f318b2d715dd9cb9cc7fe4f
Implements: blueprint ipv6-prefix-delegation
When troubleshooting problems with cluster it would be
very convenient to have information about agent heartbeats
logged with some searchable identifier which could create
1-to-1 mapping between events in agent's logs and server's logs.
Currently agent's heartbeats are not logged at all on server side.
Since on a large cluster that could create too much logging
(even for troubleshooting cases), it might make sense to make
this configurable both on neutron-server side and on agent-side.
DocImpact
Change-Id: I0a127ef274a84bba5de47395d47b62f48bd4be16
Closes-Bug: #1452582
These 2 configuration options are no longer be necessary.
They are marked as deprecated in this release and will be removed in the
next release.
Change-Id: I4e02a291738b16c7c9b7600f0bc9a47fb1318569
Partial-Bug: #1418079
There has been a problem with iproute package that resulted in errors
when deleting the namespaces, so deleting was turned off by default.
According to tests with iproute version 3.12.0 there is no such issue
so the option could be safely turned on by default.
DocImpact
Related-Bug: #1052535
Related-Bug: #1402739
Change-Id: I4c831f98fb2462382ef0f9216e265555186b965a
The problem is that if one tries to communicate from a tenant network
to floatingip which attached to a port on the same network, the
communication fails.
This problem is a regression cased by [1].
[1] https://review.openstack.org/131905/
Before [1] SNAT rule is as follows:
-s %(internal_cidr)s -j SNAT --to-source ...
(for each internal interface)
After [1] SNAT rule is as follows:
-o %(interface_name)s -j SNAT --to-source ...
(for an external interface)
The new rule was considered a super-set of the packets going out to
the external interface compared to the old rules. This is true but
there is a lack of consideration.
Note that the packet is 'going out to external interface' OR 'DNATed'
at this point since the rule:
! -o %(interdace_name)s -m conntrack ! --ctstate DNAT -j ACCEPT
was applied already. So we should consider the following three cases.
1) going out to external interface
should be SNATed. It is OK under the new rule but there was a lack
of rules for packets from indirectly connected to the router under the
old rules. ([1] fixed this.)
2) DNATed (and going out to internal interface)
2-1) came in from internal interface
should be SNATed because the return traffic needs to go through the
router to complete the conntrack association and to reverse the effect
of DNAT on the return packets. If a packet is not SNATed, the return
packet may be sent directly to the private IP of the initiator.
The old rules done SNAT in this case but the new rule doesn't.
2-2) came in from external interface
nothing to do.
This patch adds a rule for the case 2-1).
This patch also adds mangle rules to examine whether a packet came from
external interface.
Change-Id: Ifa695ac5428fb0edba60129a4d61ec0e127a5818
Closes-Bug: #1428887
Allow router-gateway-set to work even without an assigned
subnet with the net_id so as to enable IPv6 L3 routing
using the assigned LLA for the gateway.
The goal is to allow for IPv6 routing using just
the allocated LLA address for the gateway port to be
used as the external gateway to connect to the upstream
router. For this purpose router-gateway-set no
longer has a requirement of an assigned subnet.
A new config has also been added to the l3_agent.ini
to allow the user to set a valid ipv6_gateway address
to be used as the gateway for the default ::/0 route
If the ipv6_gateway config is not set and a gateway
is still created without a subnet, the gateway interface
will be configured to accept router advertisements (RAs)
from the upstream router so as to build the default route.
Unit test changes and additions reflect these changes.
APIImpact
DocImpact
UpgradeImpact
Implements: blueprint ipv6-router
Change-Id: Iaefa95f788053ded9fc9c7ff6845c3030c6fd6df
This change moves metadata proxy options shared between dhcp and l3
agents to neutron.conf. This change prepares follow-up changes allowing
to run metadata proxy with nobody user/group
Change-Id: I1828e322791b8a697765cad2f12857e3d6deae68
Related-bug: #1427228
metadata service should be requested on 169.254.169.254:80 and router
namespace iptables rules redirect the request to the metadata-ns-proxy
on 127.0.0.1:$metadata_port. But currently the metadata-ns-proxy can be
requested directly on $router-ip:$metadata_port.
To avoid such behavior, this change marks packets redirection in mangle
table (PREROUTING), redirects (PREROUTING) them in nat table, accepts
them in filter table (INPUT) using the mark. Packets send to the
metadata proxy port without mark (so directly) are dropped. The
mark can be configured through the new option metadata_access_mark.
Remark: redirected packets are not local packets (in general), so
setting metadata proxy server host to 127.0.0.1 will disallow direct
queries but so redirected queries.
DocImpact
Partial-Bug: #1187102
Change-Id: I6a9bb12c8bf68c6fcf4e4060f8dfe44a309a41da
Currently neutron-ns-metadata-proxy runs with root permissions when
namespaces are enabled on the l3 agent because root permissions are
required to "enter" in the namespace. But neutron-ns-metadata-proxy
permissions should be reduced as much as possible because it is
reachable from vms.
This change allows to change neutron-ns-metadata-proxy permissions
after its startup through the 2 new options metadata_proxy_user and
metadata_proxy_group which allow to define user/group running metadata
proxy after its initialization. Their default values are
neutron-l3-agent effective user and group.
Permissions drop is done after metadata proxy daemon writes its
pid in its pidfile (it could be disallowed after permissions drop).
Using nobody as metadata_proxy_user/group (more secure) is currently
not supported because:
* nobody has not the permission to connect the metadata socket,
* nobody has not the permission to log to file because neutron uses
WatchedFileHandler (which requires read/write permissions after
permissions drop).
This limitation will be addressed in a daughter change.
DocImpact
Partial-Bug: #1187107
Change-Id: I55c8c3fb14ed91ae8570f98f19c2cdbaf89d42fc
* Add HA mixins used by RouterInfo and LNAT3Agent
* For HA routers: Internal, external and floating IP addresses are no
longer configured by the agent. Instead the interfaces and addresses
are passed to a keepalived configuration, which configures the
addresses when the router transitions to the master state.
* Only the master instance of the router opens the metadata proxy.
This happens due to keepalived notification scripts that are
called upon state transitions.
* Extra routes are handled via keepalived virtual routes and are
no longer configured by the agent.
* HA routers create a 'HA device' on a VRRP-traffic only HA-network.
* Functional testing: Add two new tests to the L3 agent:
1) Translation of a router configuration to a keepalived
configuration.
2) HA specific events when creating a HA router - Assert that
keepalived is up, etc.
Change-Id: I83f2a5d2af42164c42773b385ba7b00872eed54e
Implements: blueprint l3-high-availability
Co-Authored-By: Assaf Muller <amuller@redhat.com>
This patch is an enhancement to the existing L3 Agent.
This allows the L3 Agent to support distributed routers
by enhancing the router object to function across
multiple nodes.
Utilized two new types of namespaces:
- FIP to handle multiple VM fips and routers per node
- SNAT to handle centralized SNAT per router
Rules and tables are enhanced and added to support routing
across distributed routers without going to a centralized
router.
Finally, a new configuration param 'agent_mode' is introduced
and it controls what the L3 agent can do: the available values
are: 'legacy', 'dvr', 'dvr_snat' (more details inline).
The l3-scheduler uses the newly introduced agent_mode to
determine what L3 agent to select during the scheduling
process.
Partially-Implements: blueprint neutron-ovs-dvr
DocImpact
Change-Id: Icead821bb74372b15aac2e5cefe8ad7f08c037ab
Co-Authored-By: Rajeev Grover <rajeev.grover@hp.com>
Restore the default value of the send_arp_for_ha configuration
parameter to 3. This parameter was set to 0 by default to
prevent kernel crashes due to bug 1273386.
Change-Id: Idbdc6ff687734776ede45127878af6ad9b8b3ca1
Closes-Bug: 1317834
This patch adds a new configuration variable for the timeout on
ovs-vsctl commands, and sets the default timeout to 10 seconds.
This is aimed at allowing users to tune the agents in order to avoid
timeout errors on their deployments.
Change-Id: I73ea0d0de49a4b4a118bc2d68ad9c093ea122717
Closes-Bug: #1254520
With this patch a l3 agent can handle
any networks by setting the neutron
parameter external_network_bridge
and gateway_external_network_id to
empty.
Related-Bug: #1234750
Related-Bug: #1194350
Change-Id: Id260a239df23951da730513f40cda490002effc3
Adds a configuration option to tell the network agents to delete
namespaces when they are no longer in use. The option defaults to
False so that the agent will not attempt to delete namespaces in
environments where this is not safe.
This has been working well in deployments where iproute2 has been
patched with commit 58a3e8270fe72f8ed92687d3a3132c2a708582dd or it is
new enough to include it without being patched.
Change-Id: Ice5242c6f0446d16aaaa7ee353d674310297ef72
Closes-Bug: #1250596
Related-Bug: #1052535
The default for send_arp_for_ha was 3 and is now 0.
This patch changes the comment in l3_agent.ini to
show the new default.
Change-Id: I77370350ffee6ad7b94aa7db341c062ebc0b7d89
This change renames everything to Neutron while providing backwards
compatible adjustments for Grizzly configuration files.
implements blueprint: remove-use-of-quantum
Change-Id: Ie7d07ba7c89857e13d4ddc8f0e9b68de020a3d19
This is a l3-agent version of 349aa3ef35.
The combination of the plugin without agent extension support
and L3NATAgentWithStateReport results in an error:
"AttributeError: No such RPC function 'report_state'".
This patch changes l3_agent_manager to be L3NATAgent instead of
L3NATAgentWithStateReport since all plugins do not support
L3NATAgentWithStateReport and having this as the default breaks
all current deployments that upgrade source without changing
their config files.
Fixes bug 1139726
Change-Id: Ibb5c04c89bfad741ec43a372cbf97445f7b3d76c
Fixes bug 1105523
The patch set adds 2 new functions:
1. register_root_helper - this enables all wanting to use
the root_helper variable. This is under the section AGENT.
2. get_root_helper - this is a helper function that returns the
root_helper. This should be used when the application used to
have the root_helper defined under the section DEFAULT. This
ensures backward compatability.
Change-Id: Iba72c4fc89ba5329ea045483287012f82b306250
Bug 1089223
RyuInterfaceDriver is eliminated, so update the example of
dhcp_agent.ini, l3_agent.ini for Ryu plugin and other OVS
based plugins.
Change-Id: Icc95c213ecd96946bd5a90d5d60df88c94cc1454
On one hand, we sync router data (including routers,
their gw ports, interfaces and floatingips) from l3_agent
to quantum server periodically if needed.
On the other hand, we notify l3 agent from quantum server when
we delete or update a router's stuff, such as floating IP,
interface and gwport and router itself.
blueprint rpc-for-l3-agent
bug #1080286
Change-Id: I60f3081975fc7164b22f9e9fa941e702a3f4c663
fixes bug 1086012
A prior change incorrectly removed the sample state_path from the
l3_agent config file. This change adds the correct sample value to the
file.
Change-Id: I10455706442c004e5d0337834b5baa3b794af5e7
fixes bug 1085249
This patch sets the default state_path to match a reasonable deployment
value instead of the devstack default.
Change-Id: Ib0c10621d91760588a68a62df8a60682d780e015
blueprint metadata-overlapping-networks
Adds Metadata for guest VMs running on Qunatum networks. This requires
a companion patchset for Nova to test.
Change-Id: I524c6fdcd6a44e46da08395fd84c1288052a69ea
Fixes bug 1042046
Sending gratuitous ARPs when a external router or a floating
IP was added in order to facilitate HA.
I am using iputils-arping package to send ARP packets. You will need
to install iputils-arping on Ubuntu and iputils on Fedora/RHEL/CentOS.
Arping locates in /usr/bin/arping on Ubuntu and locates in /sbin/arping
on Fedora/RHEL/CentOS.
Change-Id: I125dbc57b90027dc5e99ff0a5d6877843a0b02a5
bug #1042028
Allows user to invoke L3-agent in a way that limits the agent to
implementing only routers associated with a particular external network.
Thus, it is possible to have a deployment with multiple external networks,
since you can run one agent per external network.
Also makes l3-agent pay attention to router admin_state_up field.
Change-Id: Ia79d29301530718bc381c8e5a9d197de9452bce2
Fixes bug 1042104
The fix follows the patch that was done on the DHCP agent to enable
the user to configure the usage of namespaces. In the event that
namspaces are disabled the agent is limited to running only one
router. The agent needs to define the router_id that is supported.
The process in this case is:
1. create router
2. start agent with router id
Change-Id: I2a71dc009c5aea285ff9f903b3faa99b0c9f820f
Fix bug 1037815
Summary: Copy/paste the essential parts of the rootwrap
mechanism from nova/cinder into quantum. This includes
the core changes to filter.py and wrapper.py which deal
with loading filters from files pointed to by
rootwrap.conf
Detailed changes:
Transliterate the old rootwrap/*-agent.py files to
new format, and put the results in etc/quantum/rootwrap.d
Delete the *-agent.py files.
Add conf to point to etc/quantum/rootwrap.d
Add a unit test cribbed from nova to exercise the filter
mechanism
Add a unit test to exercise the actual filtered execution
Note that as written, this patch does not set the default
execute mechanism (in the agent .ini files) to rootwrap,
leaves it as sudo. That can be done in a followon
change, or in distro specific packaging.
Note also that there is still work to do around finishing
and testing the filter specs themselves. We've decided
that that is out of scope for this patch.
Change-Id: I9aba6adc5ba40b6145be5fa38c5ece3b666ae5ca
bp quantum-l3-fw-nat
router & floating IP API calls, plugin db, and agent implemented
and unit tested
Change-Id: I6ee61396d22e2fd7840aa2ff7d1f6f4a2c6e54d4