778 Commits

Author SHA1 Message Date
Harald Jensås
c8f2a30983 Reno only - Make stateless allocation segment aware
This add's a releasenote for changes:
 * https://review.opendev.org/709444
 * https://review.opendev.org/710546
 * https://review.opendev.org/710547

Related-Bug: #1864225
Related-Bug: #1864333
Related-Bug: #1865138
Change-Id: Idc7819340b37bee8ae7841d14d0143fb18ac362a
2020-03-19 23:40:33 +00:00
Igor Malinovskiy
eb6104c0ac Allow sharing of address scopes via RBAC mechanism
Neutron-lib api ref: https://review.opendev.org/#/c/707407/
Client: https://review.opendev.org/#/c/709124/
Tempest tests: https://review.opendev.org/#/c/711610/

Change-Id: I74bedae4de4eb25e5427ecb129543885a020a0a8
Depends-On: https://review.opendev.org/712633
Partial-Bug: #1862968
Closes-Bug: #1697925
2020-03-19 16:51:39 +02:00
Lucas Alvares Gomes
4824a714bf [OVN] Add support for external ports
This patch is adding support for a new port type called "external" in
core OVN.

Prior to this work, when a VM had a SR-IOV port attached to it, OVN itself
wasn't able to reply to things such as DHCP requests packets since the
OVS port was skipped. Core OVN then introduced the concept of "external"
ports which are ports deployed on a different node than the one that the
VM is running and is able to reply to such requests on behalf of the VM.

With this patch, when a port with the VNIC type "direct" and no
"switchdev" capability is created, ovn driver will then create a
logical port with the type "external" for it and add it to a default
HA Chassis Group. The port will then get bound to the "master" (higher
priority) chassis of that group.

Please note that, as a first step, this patch is creating only one HA
Chassis Group which *all* external ports will belong to. That means that
all external ports will be *scheduled onto the same node* (but it's
HA nevertheless). In the future we should enhance this behavior.

Change-Id: Ic6c4bb6c584682169f3ebd73105a847b05dddc76
Closes-Bug: #1841154
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
2020-03-09 16:07:49 +00:00
Zuul
1f79ce8736 Merge "[OVN] Add IGMP snooping support" 2020-03-09 15:29:33 +00:00
Zuul
8540345244 Merge "Support for stateless security groups" 2020-03-04 14:16:34 +00:00
Zuul
59dd469bd3 Merge "DHCPv6 - Use addr6_list in dnsmasq" 2020-03-04 11:20:45 +00:00
Aditya Reddy Nagaram
cbc473e066 Support for stateless security groups
Blueprint: stateless-security-groups

Change-Id: Iae39a89b762786e4f05aa61aa0db634941806d41
2020-03-03 16:53:42 +01:00
Lucas Alvares Gomes
7fa6c1bf39 [OVN] Add IGMP snooping support
This patch is ading IGMP snooping support in the OVN driver. Multicast
support has been introduced in core OVN upstream.

Also, the patch always sets the "mcast_flood_unregistered" config in
the OVN Logical_Switch to the same value as the "mcast_snoop" config.
This is so that OVN matches the OVS behavior which is to enable IGMP
flooding by default [0] (in OVN, by default it's false).

[0] http://www.openvswitch.org/support/dist-docs/ovs-vsctl.8.txt (grep
for "mcast-snooping-disable")

Change-Id: I32f61ba3dd06d7eacf76a74c5c44e1286f90e584
Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
2020-03-03 10:33:02 +00:00
Harald Jensås
592c2f8d91 DHCPv6 - Use addr6_list in dnsmasq
Adds a new bool option dnsmasq_enable_addr6_list, when
enabled configuration for dnsmasq will be created with a
single dhcp-host entry specifying a list of ip addresses
allocated for a port.

Previously the dnsmasq dhcp-agent driver would write a
separate dhcp-host entry for each fixed-ip of a port in
the dnsmasq hosts file. The result of the previous
behaviour is that dnsmasq will only use one of the config
entries, i.e the first one matching the mac identifier.

The trade-off is that only a single dns_assignment will
be used for IPv6 addresses within the same subnet. (But
in practice, this was always the case since only the
first config entry would be used by dnsmasq.)

Why is this neccecary:
  This is done to enable ironic provisioning over IPv6
  using DHCPv6-stateful. For background info, please
  read dnsmasq-discuss thread:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/thread.html#13671

Closes-Bug: #1861032
Change-Id: I833840e7daed2efa7efaece27cfd1ba28e0feb90
2020-03-03 11:03:36 +01:00
Brian Haley
5af046fd4e Remove extra header fields in proxied metadata requests
If a user specifies a header in their request for metadata,
it could override what the proxy would have inserted on their
behalf. Make sure to remove any headers we don't want, and
override something that might be present in the request.
If the agent somehow gets a request with both headers it will
silently drop it.

Change-Id: Id6c103b7bcebe441c27c6049d349d84ba7fd15a6
Closes-bug: #1865036
2020-03-02 11:20:25 -05:00
Zuul
e9acdb06fa Merge "Deprecate config option "ovs_integration_bridge"" 2020-02-18 20:15:24 +00:00
Hang Yang
6dbba8d5ce Check SG members instead of ports to skip flow update
Security group can have a state of empty ports but non-empty members. So
we need skip the flow update only when members dict is empty.

Change-Id: I429edb3d2dea5fa97441909b4d2c776f97f0516f
Closes-Bug: #1862703
Related-Bug: #1854131
2020-02-17 23:50:19 -08:00
Rodolfo Alonso Hernandez
33fb446add Deprecate config option "ovs_integration_bridge"
Remove this duplicated option and rely only in OVS.integration_bridge.

NOTE: other projects are still using it; first we need to deprecate it
      in those projects.

Change-Id: I4e826c8b9fa764b1820adacc3427934dc393c0bc
Related-Bug: #1856152
2020-02-17 11:02:16 +00:00
Rodolfo Alonso Hernandez
a05a3ba413 Remove plugins.ml2.db.get_binding_levels
This method was deprecated in Stein and marked for removal in Train.

Trivial-Fix

Change-Id: I6e25974bd244dbc36d2bdc94de5fc4a85704b787
2020-02-07 09:26:42 +00:00
Zuul
e17464ad11 Merge "Enable bulk updates for the dnsmasq" 2020-02-03 04:03:30 +00:00
Zuul
cb95815649 Merge "Add description field to portforwarding NAT rules" 2020-01-31 15:43:23 +00:00
Zuul
520f7cb4a0 Merge "Implement tagging during bulk port creation" 2020-01-30 15:26:44 +00:00
Miguel Lavalle
e22a191f47 Implement tagging during bulk port creation
This change proposes a ML2 plugin extension to implement tagging during
bulk port creation.

Change-Id: Ic70f7d282db478c69016ab1c317c5cae786401ce
Related-Bug: #1815933
2020-01-28 18:23:37 -06:00
Zuul
da75a91b78 Merge "Add accepted egress direct flow" 2020-01-26 13:34:01 +00:00
Pedro Henrique
06e43dd95d Add description field to portforwarding NAT rules
Add the `description` field to `PortForwardings`
using the standard attributes like in the
`FloatingIPs`.

Depends-On: https://review.opendev.org/#/c/692580/
Depends-On: https://review.opendev.org/#/c/698662/
Implements: blueprint portforwarding-description
Closes-Bug: #1850818
Change-Id: Ibac91d24da2b82cdce72165d1295fa5d4475ffd3
Signed-off-by: Pedro Martins <phpm13@gmail.com>
2020-01-22 11:19:55 -03:00
Zuul
6737c0877f Merge "Add support for direct ports with QoS in OVS" 2020-01-22 00:16:09 +00:00
waleed mousa
12089a526e Add support for direct ports with QoS in OVS
Today OVS mechanism driver can bind Direct port see [1] for OVS hardware
offloads.
OVS was extended with tc-offload to support rate limit see [2].
The OVS QoS driver [3] is limited to work only with Normal Ports, so we
can't put QoS rules on direct port.
This patch proposes to add support in OVS QoS driver for direct ports.
The mechanism to enforce such policies is the same with normal and
hardware offloaded direct ports.

[1] - e7f6ba220e
[2] - 3b074128ca/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py (L83)
[3] - 3b074128ca/neutron/services/qos/drivers/openvswitch/driver.py (L56)

Change-Id: I24b5cd6c022e479080fc84e4c445c9cddfc88e38
Closes-Bug: #1843165
2020-01-16 11:50:02 +00:00
Bence Romsics
03ad5bf19c Fix bug number in release note
I mixed up the bug number and the gerrit change number in a previous
release note.

TrivialChange

Change-Id: I7599be8b7459c44db8e34d0de536154dccb19134
Related-Bug: #1853840
2020-01-14 11:11:28 +01:00
LIU Yulong
efa8dd0895 Add accepted egress direct flow
Do not flood the packets to bridge, since we have the
bridge port list, we can add a simple direct flow to
the right port only.

Closes-Bug: #1732067
Related-Bug: #1841622
Change-Id: I14fefe289a19b718b247bf0740ca9bc47f8903f4
2020-01-10 22:50:02 +08:00
OpenStack Proposal Bot
2a8b5860a0 Imported Translations from Zanata
For more information about this automatic import see:
https://docs.openstack.org/i18n/latest/reviewing-translation-import.html

Change-Id: I78cbd02c7dc0c60b12c9c4e90046336157b8bcb1
2019-12-21 07:16:10 +00:00
Zuul
250d8a61c8 Merge "Allow to select subnets to publish DNS records" 2019-12-20 12:31:51 +00:00
Zuul
49f905150d Merge "Locate RP-tree parent by hypervisor name" 2019-12-19 17:01:22 +00:00
Zuul
1e19349a16 Merge "Support L3 agent cleanup on shutdown" 2019-12-18 15:38:10 +00:00
Oleg Bondarev
5663517613 Support L3 agent cleanup on shutdown
Add an option to delete all routers on agent shutdown.

Closes-Bug: #1851609
Change-Id: I7a4056680d8453b2ef2dcc853437a0ec4b3e8044
2019-12-16 17:01:31 -05:00
Jens Harbott
57bc6d167b Allow to select subnets to publish DNS records
As described in [0] a new attribute ``dns_publish_fixed_ip`` is added
to subnets, allowing to specify directly whether DNS records should be
published for this subnet. This overrides the previous behaviour that
makes this decision based on various properties of the network that
the subnet is contained in, see [1].

[0] https://launchpad.net/bugs/1784879
[1] https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html

Change-Id: I14605ead2694d9e9422b3d7b519aed2e3c340e2a
Partial-Bug: 1784879
2019-12-14 13:36:09 +00:00
Zuul
e04e1d80e4 Merge "List SG rules which belongs to tenant's SG" 2019-12-12 23:15:00 +00:00
Bence Romsics
258eebea71 Locate RP-tree parent by hypervisor name
Previously we assumed that we can look up the resource provider (created
by nova) to be used as the parent of the agent and physical NIC resource
provider tree by the name set in the config option DEFAULT.host. This
assumption was wrong.

While nova-compute's DEFAULT.host and neutron-agent's DEFAULT.host
must match for port binding to work, the root resource provider created
by nova does not belong to the compute host (where nova-compute runs)
but it belongs to the compute nodes (i.e. hypervisors). Actually there
may be multiple compute nodes managed by a single nova-compute (think
of ironic). Plus the value of DEFAULT.host and the compute node's ID
may be different even when nova-compute manages a hypervisor on the
same host because of various deployment considerations. For example
when tripleo does not manage the undercloud (so a libvirt hypervisor
returns the plain hostname), but the same tripleo enforces it's host
naming conventions in nova's and neutron's DEFAULT.host settings.

This change enables neutron to use the hypervisor name to locate the
root of the resource provider tree.

We introduce a new configuration option for

(1) ovs-agent: resource_provider_hypervisors, for example:

[ovs]
bridge_mappings = physnet0:br-physnet0,...
resource_provider_bandwidths = br-physnet0:10000000:10000000,...
resource_provider_hypervisors = br-physnet0:hypervisor0,...

(2) sriov-agent: resource_provider_hypervisors, for example:

[sriov_nic]
bridge_mappings = physnet1:ens5,...
resource_provider_bandwidths = ens5:10000000:10000000,...
resource_provider_hypervisors = ens5:hypervisor1,...

For both agents 'resource_provider_hypervisors' values default to
socket.gethostname() for each key in resource_provider_bandwidths.

We try to not block later developments in which one neutron
agent may manage devices on multiple hosts. That's why we allow
the each physdev to be associated with a different hypervisor.

But here we do not try to solve the problem that the natural physdev
identifiers may not be unique accross multiple hosts. We leave solving
this problem to whoever wants to implement an agent handling devices of
multiple hosts.

(3) We extend report_state message's configurations field alike:

{
'bridge_mappings': {'physnet0': 'br-physnet0'},
'resource_provider_bandwidths': {
    'br-physnet0': {'egress': 10000000, 'ingress': 10000000}},
'resource_provider_hypervisors': {'br-physnet0': 'hypervisor0'},
...
}

(4) In neutron-server we use
report_state.configurations.resource_provider_hypervisors.PHYSDEV
when selecting parent resource provider for agent and physdev
RP-tree. When not available in the message we fall back to using
report_state.host as before.

Since we only changed the free-format configurations field of the
report_state message rpc version is not bumped and we expect this
change to be backported to stein and train.

Change-Id: I9b08a3a9c20b702b745b41d4885fb5120fd665ce
Closes-Bug: #1853840
2019-12-10 10:21:53 +01:00
Zuul
c97d3268ca Merge "doc: fixed word 'neutron-serer' spelling error" 2019-12-09 15:16:59 +00:00
Zuul
239c0f2683 Merge "Force arp_responder to True when DVR and tunneling enabled" 2019-12-07 16:25:51 +00:00
yanhongchang5
ec171b06f0 doc: fixed word 'neutron-serer' spelling error
there is a spelling error in the document, the 'neutron-server'
was wrongly written as 'neutron-serer'.

Change-Id: I5e6995f46474570289dfb76caaad86a3494a2bbd
Related-Bug: #1854687
2019-12-06 19:34:28 +08:00
Slawek Kaplonski
b898d2e3c0 List SG rules which belongs to tenant's SG
In case when user's security group contains rules created e.g.
by admin, and such rules has got admin's tenant as tenant_id,
owner of security group should be able to see those rules.
Some time ago this was addressed for request:

GET /v2.0/security-groups/<sec_group_id>

But it is also required to behave in same way for

GET /v2.0/security-group-rules

So this patch fixes this behaviour for listing of security
group rules.
To achieve that this patch also adds new policy rule:
ADMIN_OWNER_OR_SG_OWNER which is similar to already existing
ADMIN_OWNER_OR_NETWORK_OWNER used e.g. for listing or creating
ports.

Change-Id: I09114712582d2d38d14cf1683b87a8ce3a8e8c3c
Closes-Bug: #1824248
2019-11-27 15:45:09 +01:00
Zuul
f0db43df55 Merge "Dont schedule Network, respecting network_auto_schedule config" 2019-11-27 06:05:14 +00:00
Reedip
139b496ef9 Dont schedule Network, respecting network_auto_schedule config
Currently, if dhcp mapping from a network is removed, it is reassigned
to the network. This is because of the Network Scheduler's schedule
function, which considers balancing the networks with the agents, whether
enable_dhcp is set on its subnets or not. It does not take into account
the network_auto_schedule config option. This is particularly disturbing
when considering backends which have their provide their own DHCP.

With this patch, if network_auto_schedule is set to False, networks wont
be automatically scheduled to DHCP Agents. If DHCP is to be mapped to a
network, it can be mapped using the CLI itself.

While it may seem that this change is breaking what is already working,
but as mentioned earlier, if there are network backends which provide DHCP
support themselves, they wont need the automatic mapping, which the term
"network_auto_schedule" actually stands for.

Closes-Bug: #1647421
Change-Id: If1a6a2a174d0f737415efa2abce518722316a77b
2019-11-26 01:55:03 +00:00
Zuul
2a8b70d2db Merge "Update security group rule if port range is all ports" 2019-11-26 00:23:06 +00:00
Brian Haley
ea85e39660 Force arp_responder to True when DVR and tunneling enabled
After [1] and [2], the ARP responder needs to be enabled
if DVR and tunneling are enabled or ARP will not work. If
it is False we will log a message and force it to True.

[1] https://review.opendev.org/#/c/651905/
[2] https://review.opendev.org/#/c/653883/

Change-Id: I934062c970effe5194056b0786f84f3246850701
Related-bug: #1774459
2019-11-25 16:33:15 -05:00
Zuul
d6cde7b05b Merge "SR-IOV: macvtap assigned vf check using sysfs" 2019-11-16 14:07:35 +00:00
Adrian Chiris
76de8a715d SR-IOV: macvtap assigned vf check using sysfs
This reverts commits:
 9a022e7d7b85b7c21cf26698fe59c818c4577194
 d7604169988726d121cdc9727accfeb6e29f4aed

As the issue is relevant only for old kernels and almost 4 years
have passed since this fix was introduced, it is safe to undo the
workaround to use ip link show command for determining whether or not
a VF is assigned with macvtap(and followup patch that fixed excessive
use of ip link show commans).

reverting this commit will benefit the agent by reducing the amount of
ip link calls.

While it is possible to perform a revert-per-commit, this change should
really go in as one commit for clarity and avoid introducing a
performance degradation in case one is merged without the other.

 Conflicts:
	neutron/plugins/ml2/drivers/mech_sriov/agent/eswitch_manager.py
	neutron/plugins/ml2/drivers/mech_sriov/agent/pci_lib.py
	neutron/tests/unit/plugins/ml2/drivers/mech_sriov/agent/test_eswitch_manager.py
	neutron/tests/unit/plugins/ml2/drivers/mech_sriov/agent/test_pci_lib.py

 Conflicts details:
   In eswitch_manager: merge tool was unable to properly revert
                       is_assigned_vf() due to changes in later patches.
   In pci_lib: conflicts with later changes to is_macvtap_assigned()
               and link_show() that are no longer required and revert
               of IPCommandDeviceError definition.
   In unit tests: conflicts due to newly added tests and reverting the
                  IPCommandDeviceError exception definition.
                  Sorting out mocks as link_show() method was removed

Related-bug: #1523083

Change-Id: I04ea8eb63de07a6e1e51c2790c5920b086b8542c
2019-11-11 17:13:00 +02:00
Gary Kotton
a545da420c Enable bulk updates for the dnsmasq
Instead of restarting the dnsmasq agent for every IP we do this
in bulk. That is, if a network has N updates in X seconds then we will
restart the process once with the ports configured in the X seconds and
not N Times.

A new configuration variable have been added:

- bulk_reload_interval - time to wait between bulk reloads. This is 0 by
  default to ensure backwards compatibility. If the value is not 0 the
  new functionlay is invoked.

Change-Id: Ieff5ce4506fd4e7fa427eb50c50fbe316f67103f
2019-11-06 05:35:08 +00:00
Zuul
7fe44be27d Merge "Add "igmp_snooping_enable" config option for OVS agent" 2019-11-05 11:08:13 +00:00
Slawek Kaplonski
5b341150e2 Add "igmp_snooping_enable" config option for OVS agent
Neutron-ovs-agent can now enable IGMP snooping in integration bridge
if config option "igmp_snooping_enable" in OVS section in config will
be set to True.
It will also set mcast-snooping-disable-flood-unregistered=true
so flooding of multicast packets to all unregistered ports will be
disabled also.
Both changes are applied on integration bridge.

Change-Id: I12f4030a35d10d1715d3b4bfb3ed5efb9aa28f2b
Closes-Bug: #1840136
2019-11-02 13:46:13 +01:00
Zuul
188a057d11 Merge "Remove deprecated agent_type option" 2019-11-02 11:59:34 +00:00
Slawek Kaplonski
02be7c13b3 Remove deprecated agent_type option
This config option was added by [1] and deprecated to
be removed in Mitaka cycle. As we are now in Ussuri, it's
time to finally get rid of it.

[1] https://review.opendev.org/#/c/197210/

Change-Id: Ibd16a0587c88e2dbee1b7938e52140f68821eec6
2019-11-01 18:59:37 +00:00
Brian Haley
26b8026cee Update security group rule if port range is all ports
A security group rule where port_range_min:port_range_max
is 1:65535 is specifying all ports, but it is not optimal
for backends to try and implement this potentially large
rule.

Since it is essentially the entire port range, change
min:max to be None, making the rule specify the entire
protocol instead.

Change-Id: Iff22e2fc84d679e20a5a04b8516750c6ea949078
Closes-bug: #1848213
2019-10-31 14:48:47 +00:00
zhanghao
68625686a4 Make the MTU attribute not nullable
This patch sets the MTU attribute to non-nullable, the code
that get the MTU and update the network in some methods can
be removed. If the MTU is empty before the pike version, it
is set to the default value of 1500.

Change-Id: Id4d738dde7fa4b7caccabad0aac542b82b4d7af1
Closes-Bug: #1842261
2019-10-28 03:32:50 +00:00
Brian Haley
6842465260 Stop testing python 2
Since it's no longer supported past Train, lets stop
running the tests.

Updated docs and made some pep8 code tweaks as well.

Change-Id: I1c171ab906a3b4c66558163ad26947ebf710a276
2019-10-25 18:50:08 +00:00