This plugin didn't decompose in the last two cycles, I failed
to spot a functional CI, and there hasn't been any meaningful
activity done in the subtree for the past couple of cycles
I think it is time to implement the eviction.
Related-blueprint: core-vendor-decomposition
Change-Id: I949a51873ee5af654b577952d423dd29a6ced8e7
This option does not have a clear use case since we prevent
users from setting their own IP addresses on shared networks.
DocImpact
Change-Id: I211e87790c955ba5c3904ac27b177acb2847539d
Closes-Bug: #1502356
This patch adds the availability_zone attribute to agents and
supports availability_zone API.
Availability_zone support for resources (network/router) and
the schedulers are included in subsequent patches.
APIImpact
DocImpact
Co-Authored-By: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
Change-Id: Id7a62000ab0484412b3970199df8c374568fe70d
Partially-implements: blueprint add-availability-zone
This plugin didn't decompose in the last two cycles, the CI has
stopped working for a while and it seems there is no pulse since
March 2015.
I think it is time to implement the eviction.
Change-Id: Ib2cb1e3f05330c7808177b0312506d0e56254aa8
Related-blueprint: core-vendor-decomposition
This change introduces a new agent_type config option which
allows the ovs agent to be reused by out of tree
mechanism drivers.
DocImpact
Change-Id: I48f4be4b1d51bcff62e86e5814c12bd9bfa3c902
Closes-Bug: #1469871
_kill_process kills processes with SIGKILL, which prevents the
processes' cleanup from running. Issue SIGTERM first and wait a bit.
Change-Id: Ie7b94011bbd11b1d672c95e3be19bb3c84ef77ec
Closes-bug: 1494363
Cloud deployed at scale most likely will use these scheduler
drivers because they allow a fairer resource allocation compared
to chance schedulers (which randomly place resources on the hosts).
Because of their importance, it's only wise to test them in
the gate on a continuous basis, so that we do not get surprised
by accidental regressions.
Rather than pushing this down through devstack-gate/project-config
patches, this chance alters the default of the scheduler
drivers, so that users can also pick these up out of the box.
This means that after an upgrade they would observe a change in
the scheduling behavior, if they relied on the default config.
DocImpact
UpgradeImpact
Closes-bug: #1494667
Change-Id: I5927914cb88eff66bc7a045340ff68cb8da95ad6
Previous changes[1] have been merged as enablers[2] to fix the bug
1274034 but an alternative solution has been choosen and now we can
consider the introduced code as dead code.
This changes removes [2], associated tests and rootwrap filters.
[1] I9ef57a86b1a1c1fa4ba1a034c920f23cb40072c0
I3c66e92cbe8883dcad843ad243388def3a96dbe5
[2] neutron.agent.linux.ebtables_driver
neutron.agent.linux.ebtables_manager
Closes-Bug: #1493422
Related-Bug: #1274034
Change-Id: I61e38fc0d8cf8e79252aabc19a70240be57e4a32
This patch adjusts the FieldCheck class in the policy engine to
allow a regex rule. It then leverages that to prevent users from
setting the device_owner field to anything that starts with
'network:' on networks which they do not own.
This policy adjustment is necessary because any ports with a
device_owner that starts with 'network:' will not have any security
group rules applied because it is assumed they are trusted network
devices (e.g. router ports, DHCP ports, etc). These security rules
include the anti-spoofing protection for DHCP, IPv6 ICMP messages,
and IP headers.
Without this policy adjustment, tenants can abuse this trust when
connected to a shared network with other tenants by setting their
VM port's device_owner field to 'network:<anything>' and hijack other
tenants' traffic via DHCP spoofing or MAC/IP spoofing.
Closes-Bug: #1489111
Change-Id: Ia64cf16142e0e4be44b5b0ed72c8e00792d770f9
The new option for the ovs agent will enable to set/unset the
csum option for the vxlan/gre tunnels. The default is maintained as False.
Change-Id: I18dcd8946b585e70f8890a5c222ea37059c4a0c5
Implements: bp ovs-tunnel-csum-option
Closes-bug: #1492111
This patch follows the previous patch(listed as dependent) and moves
the remaining cisco db models from neutron to networking-cisco.
The patch deletes l3_model and cisco_router_plugin and their associated
config and helper files from neutron
Change-Id: I5b71e1dfb683e633e1cd11386dfb7c2ed7cc7d62
Partial-Bug: #1489609
This patch removes the Cisco meta plugin and the Cisco
Nexus1000V monolithic plugin as they were deprecated in the
previous cycle.
Closes-bug: #1473217
Change-Id: Id170b9512b2f52a971264336d83b083d487359ee
There are several cases where plugin initialization should be
handled after neutron-server forks API/RPC workers. For example,
starting a client connection to an SDN controller before forking
copies the fd of the socket to the child process, but then you have
multiple processes trying to read/write the same socket connection.
It is also useful for a plugin to be able to do something in only
one process, regardless of how many workers are forked. One example
would be handling syncing from an external system to the neutron
database.
This patch does 3 things:
1) Treats rpc_workers=0 as = 1. This simplifies the code for
handling notification that forking has completed. In the
existing code, calling the notification in the Worker object's
start() method would happen twice in the case where both api
and rpc workers were 0, despite there being only one process.
An earlier patch already changed the default api_workers to be
the number of processors.
2) Adds notification of forking via the callbacks mechanism.
Plugins can subscribe to resources.PROCESS, event.AFTER_CREATE
and do any post-fork initialization that needs to be done for
every spawned process.
3) Adds core/service plugin calls to get_workers() which defaults
to returning (). Plugins that need additional processes to spawn
should just return an iterable of NeutronWorkers that will be
spawned in their own process.
DocImpact
Closes-Bug: #1463129
Change-Id: Ib99954678c2b4f32f486b537979d446aafbea07b
Introduce an alternative OpenFlow implementation, "native",
implemented using Ryu ofproto python library from Ryu SDN Framework.
Make it selectable with of_driver=native agent option.
The aim is to replace the existing ovs-ofctl based implementation
eventually.
It introduces node-local OpenFlow controller embedded in
OVS agent. Benefits include:
* Reduce the overhead of invoking ovs-ofctl command (and associated
rootwrap)
* Make future uses of OpenFlow asynchronous messages (e.g. Packet-In,
Port-Status, etc) easier
* Make XenAPI integration simpler
Highlights:
* Switch to OpenFlow 1.3.
* Make OVS-agent act as an OpenFlow controller
* Configure OVS on the node to connect to the controller
DocImpact
Implements: blueprint ovs-ofctl-to-python
Co-Authored-by: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
Change-Id: I02e65ea7c6083b2c0a686fed2ab04da4d92b21a3
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 is the same as we do for linuxbridge or openvswitch. We should not
expose server-only configuration options to the agent, and vice versa.
DocImpact
Closes-Bug: #1489060
Change-Id: Ie1eda925e051f85d53ad9624d6617d095cf8c7be
Neutron doesn't have a way to test a newly added network node
by deploying test resource before any customer resource on the node
is deployed. Nova and Cinder has the setting of “enable_new_services”
in each conf to disable the initial service status to achieve this.
This proposal adds enable_new_agents config.
DocImpact
Change-Id: Ie0d0b2dd4d95de95f3839d1c35f24b708e893801
Implements: blueprint enable-new-agents
Related-Bug: 1472076
More information about Geneve protocol can be found here:
https://tools.ietf.org/pdf/draft-gross-geneve-02.pdf
Following configuration variables were added:
[ml2_type_geneve]
vni_ranges - Comma-separated list of <vni_min>:<vni_max> tuples
enumerating ranges of Geneve VNI IDs that are
available for tenant network allocation
max_header_size - Geneve encapsulation header size is dynamic, this
value is used to calculate the maximum MTU for the driver
this is the sum of the sizes of the outer
ETH + IP + UDP + GENEVE header sizes
DocImpact
Change-Id: I8c29a1c1a7c79e02c26ac9e2ad2645d30dfbeefc
Closes-Bug: #1461069
As the SDN-VE monolithic plugin is no longer in use by
anyone, this is to remove the code from the Neutron source
tree.
DocImpact
Change-Id: I8def7fc2e92f967785b9ab05f8496de641e8f866
When SR-IOV introduce in Juno Agent supported only link state change
Some Intel cards don't support setting link state, so to
resolve it the SR-IOV mech driver supports agent and agent less mode.
From Liberty the SR-IOV agent brings more functionality like
qos and port security so we want to make the agent mandatory.
(of course I already talked with Intel Guys to get their approval)
This patch deprecates the agent_required in Liberty
and updates the agent_required default to be True.
DocImpact
Closes-bug: #1488807
Change-Id: I8799425c2825415ef05bec909e6b4085ffc1e3c5
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
As part of plugin decomposition effort, NEC plugin is removed
from the main neutron repo and moved to networking-nec repo.
Related blueprint core-vendor-decomposition
Closes-Bug: #1487929
Change-Id: I2ef7ec241f061516b72c4df9f959af027c4c366c
Functionallity is added to enable users to specify a dns_label field during
port creation and update. This dns_label field will be used for DNS resolution
of the hostname in dnsmasq and also will be used when Neutron can integrate
with external DNS systems.
Change-Id: I6beab336dfd9b70b1af6e975939c602047faa651
DocImpact
APIImpact
Closes-Bug: #1459030
Implements: blueprint internal-dns-resolution
Without this empty policy rule, get_rule_type will use default, which
will demand admin role or tenant_id in object. but rule_type has no
tenant_id in its body.
Change-Id: I92b1222fbcdc2efd13ca6f586cfefefc55b59189
Closes-bug: #1487324
Vendors implementing Neutron L3 API in their devices may not be able to provide
metadata server access via the Neutron router. In such cases we want to allow
the metadata service as done for non-isolated networks segments.
DocImpact
Change-Id: I5f6ee9788717c3d4f1f2e2a4b9734fdd8dd92b40
Closes-Bug:#1483939
This update will allow for local executables that require root
privileges, such as dibbler-client for IPv6 Prefix Delegation.
Change-Id: Id7aebb50e60b1cc64c113be63c599387be5f1765
This change introduces a new datapath_type parameter
to allow specification of the ovs datapath to be used.
This change introduces new functional and unit tests.
DocImpact
Change-Id: I929d8d15fc6cfdb799c53ef0f3722f4ed5c1096d
Partial-Bug: #1469871