They were deprecated in Newton. This patch cleans them up.
Note: it does not mean that the features will not work anymore. On the
contrary, now API will consistently sort and paginate for plugins that
honour the relevant sorting/pagination parameters.
Note2: base resource controller still allows to pass
allow_pagination=False and allow_sorting=False parameters to disable the
features if a registered plugin does not support the features yet.
Change-Id: I5fd30b20f645846d9366740372c4815c4b33e2eb
Related-Bug: #1566514
There are still valid use cases to keep using physical_device_mappings
config option. We still want to allow neutron user to restrict physnets,
for example, if API user does not enforce compatible segments chosen for
a SR-IOV port.
This reverts commit 03b84bc920b5499e1fef23c646268fffa1d859d7.
Change-Id: Ic373a0ab62c610fae1cbdaf489ba27e9cf02ba5b
These were deprecated in https://review.openstack.org/247906
Now that Liberty is EOL we can remove these legacy entrypoints.
Closes-Bug: #1639103
Change-Id: I94e61cb219b23ce2f5d0f34dc9ae1c87650568bd
This patch updates code to use Pike as the code name:
Pike is the code name for the P release
Ocata is the code name for the O release
Change-Id: Iec8494b40fed2d427c1edf4609f8b3dd8c770dce
We rely on keepalived to send gratuitous ARPs when floating IP is added.
Older versions of keepalived up to 1.2.20 (exclusive) contain bug [1] where
keepalived does not send GARP on receiving SIGHUP. Unfortunately, newer
versions containing the fix are not packaged yet for some distributions
like RHEL or CentOS or Ubuntu Xenial, so this patch adds a workaround for
such distributions until new packages are available.
The patch also sets net.ipv4.ip_nonlocal_bind kernel parameter to 0 for
Snat and HA router namespaces in order to avoid sending gratuitous ARPs
for IP addresses that are not bound to the interface anymore - possibly
because of failover or removal. Note that kernel < 3.19 contain a bug
where this knob is missing. In case it attempts to set the parameter and
it's missing on the system, it doesn't set the knob in root
namespace like it's done for fip namespaces, but only issues a warning
message.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1391553
Change-Id: Ieab53624dc34dc687a0e8eebd84778f7fc95dd77
Closes-bug: 1639315
The device to physnet validation is made in Nova by pci_whitelist config option.
Therefore it is redundant to validate it in Neutron with physical_device_mappings
config option.
Closes-Bug: #1640220
DocImpact
Change-Id: I5f363347b327212a49a9b78a7164c11d9e457b10
It puzzles me why we would want to have it configurable. Having it = 0
is just plain bad (it breaks a floating IP roaming around HA routers),
having it = 1 may be unsafe if clients miss the update, having it more
than 3 (the default) is probably wasteful. That makes me think that
maybe we should not have it in the first place.
The patch that introduced the option also introduced the feature itself,
and does not provide any clue around why we would need it:
I125dbc57b90027dc5e99ff0a5d6877843a0b02a5
Maybe the option is in the tree because, in Assaf Muller's words, "we're
a bunch of lazy developers that like to shift the responsibility to our
poor users that have to deal with thousands of configuration options".
I suggest we just move with deprecation and removal here.
Change-Id: I9d12b8f4c25ddf91312153f236915c0c14302e2d
Related-Bug: #1639879
This sets up the HTTPProxyToWSGI middleware in front of Neutron-API. The
purpose of this middleware is to set up the request URL correctly in
case there is a proxy (For instance, a loadbalancer such as HAProxy)
in front of Neutron.
So, for instance, when TLS connections are being terminated in the
proxy, and one tries to get the versions from the / resource of
Neutron, one will notice that the protocol is incorrect; It will show
'http' instead of 'https'. So this middleware handles such cases.
Thus helping Keystone discovery work correctly.
The HTTPProxyToWSGI is off by default and needs to be enabled via a
configuration value.
Change-Id: Ice9ee8f4e04050271d59858f92034c230325718b
Closes-Bug: #1590608
The Hyper-V Neutron plugin was fully decomposed from neutron
and moved into the networking-hyperv project.
The only thing that remained was a debtcollector move for the
HyperVSecurityGroupsDriver, in order to prevent deployments from
breaking when upgrading to Mitaka or Newton from older versions.
Co-Authored-By: Gary Kotton <gkotton@vmware.com>
Change-Id: Iddc14fc4c52ba1a851e79bcd4cf4f09c63b52312
Releasenote translation publishing is being prepared. 'locale_dirs'
needs to be defined in conf.py to generate translated version of the
release notes.
Note that this repository might not get translated release notes - or
no translations at all - but we add the entry here nevertheless to
prepare for it.
Change-Id: Ic0d37f26c59aeed3a55a5b229404c1d18bf248f0
For new kernels (3.18+), bridge module is split into two pieces: bridge
and br_netfilter. The latter provides firewall support for bridged
traffic, as well as the following sysctl knobs:
* net.bridge.bridge-nf-call-arptables
* net.bridge.bridge-nf-call-ip6tables
* net.bridge.bridge-nf-call-iptables
Before kernel 3.18, any brctl command was loading the 'bridge' module
with the knobs, so at the moment where we reached iptables setup, they
were always available.
With new 3.18+ kernels, brctl still loads 'bridge' module, but not
br_netfilter. So bridge existance no longer guarantees us knobs'
presence. If we reach _enable_netfilter_for_bridges before the new
module is loaded, then the code will fail, triggering agent resync. It
will also fail to enable bridge firewalling on systems where it's
disabled by default (examples of those systems are most if not all Red
Hat/Fedora based systems), making security groups completely
ineffective.
Systems that don't override default settings for those knobs would work
fine except for this exception in the log file and agent resync. This is
because the first attempt to add a iptables rule using 'physdev' module
(-m physdev) will trigger the kernel module loading. In theory, we could
silently swallow missing knobs, and still operate correctly. But on
second thought, it's quite fragile to rely on that implicit module
loading. In the case where we can't detect whether firewall is enabled,
it's better to fail than hope for the best.
An alternative to the proposed path could be trying
to fix broken deployment, meaning we would need to load the missing
kernel module on agent startup. It's not even clear whether we can
assume the operation would be available to us. Even with that, adding a
rootwrap filter to allow loading code in the kernel sounds quite scary.
If we would follow the path, we would also hit an issue of
distinguishing between cases of built-in kernel module vs. modular one.
A complexity that is probably beyond what Neutron should fix.
The patch introduces a sanity check that would fail on missing
configuration knobs.
DocImpact: document the new deployment requirement in operations guide
UpgradeImpact: deployers relying on agents fixing wrong sysctl defaults
will need to make sure bridge firewalling is enabled.
Also, the kernel module providing sysctl knobs must be
loaded before starting the agent, otherwise it will fail
to start.
Depends-On: Id6bfd9595f0772a63d1096ef83ebbb6cd630fafd
Change-Id: I9137ea017624ac92a05f73863b77f9ee4681bbe7
Related-Bug: #1622914
Currently max number of client connections(i.e greenlets spawned at
a time) opened at any time by the WSGI server is set to 100 with
wsgi_default_pool_size[1].
This configuration may be fine for neutron api server. But with
wsgi_default_pool_size(=100) requests, state change server
is creating heavy cpu load on agent.
So this server(which run on agents) need lesser value i.e
can be configured to half the number of cpu on agent
We use "ha_keepalived_state_change_server_threads" config option
to configure number of threads in state change server instead of
wsgi_default_pool_size.
[1] https://review.openstack.org/#/c/278007/
DocImpact: Add new config option -
ha_keepalived_state_change_server_threads, to configure number
of threads in state change server.
Closes-Bug: #1581580
Change-Id: I822ea3844792a7731fd24419b7e90e5aef141993
Commit 2aa23de58f55f7b1001508326c5ac2627ba3a429 added in a warning
in the event that a release failed. This would have no information
that can help anyone deal with it.
Also updated the release note to include a recommendation to use
a version of dnsmasq including dhcp_release6 on an upgrade, so
that the warning we are logging here will not happen.
Closes-bug: #1619535
Change-Id: Ia73dcf5170aaf3f874a6abe83fefb8e85b6e67e3
The Neutron 'created_at'/'updated_at' fields on API resources
were inconsistent with other OpenStack projects because we did
not include timezone information. This patch addressed that
problem by adding the zulu time indicator onto the end of the
fields.
Because this could break clients expecting no timezone, this patch
also eliminates the 'timestamp_core' and 'timestamp_ext' extensions
and consolidates them into a new 'timestamp' extension. This makes
the change discoverable via the API.
This is assuming the current API development paradigm where
extensions can come and go depending on the deployment and the client
is expected to handle this by checking the loaded extensions.
Once we decide extensions are permanent, this type of change will
no longer be possible.
Even though this is being proposed late in the cycle, it is better
to get this change in before the release where we expose even more
resources with incorrectly formatted timestamps.
APIImpact
Closes-Bug: #1561200
Change-Id: I2ee2ed4c713d88345adc55b022feb95653eec663
Update the API to accept project_id in requests and return
project_id in responses.
For now, the API treats tenant_id and project_id equivalently.
It accepts either or both in requests.
It returns both in responses, depending on filters.
We include an extension to indicate that support for project_id
is enabled in the API.
Completes: blueprint keystone-v3
APIImpact: Describe how the Networking API supports Keystone V3.
Co-Authored-By: Henry Gessau <HenryG@gessau.net>
Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
Change-Id: I8775aa8a477191ef21e7c3c6da31d098befefc3c
Now that the bulk of the code is in place, and we are about
to see the finish line, it is time to prepare the release
notes for this feature.
This patch refines docstrings that recently went in and
makes sure the code is in sync with the agent's devref.
Implements: blueprint vlan-aware-vms
Change-Id: Idb9379046aeb07354a170a361da777140a2a028e
This is the Neutron side of the unaddressed ports blueprint. In order
to allow unaddressed ports, Nova wants the port to explicitly say it
is okay that it doesn't have any IP addresses.
In Neutron, an unaddressed port is one that was created by explicitly
passing [] in fixed_ips to create the port. A new DB field is added
to the port to distinguish the unaddressed port case from the deferred
IP allocation case where routed networks is involved.
Change-Id: Ia61af4c14e955697a7d3fcc0bf4826a6d9475c98
Implements: blueprint vm-without-l3-address
APIImpact: port now has ip_allocation attribute, set on port create
This was marked as deprecated in commit 95dbd03a0bc4867bf8520539ed08f4068adf2f33.
That was in Havana. We have given enough time for admins
to upgrade to the new variable - dhcp_lease_duration.
UpgradeImpact
TrivialFix
Change-Id: Ie08c8f66b84cc577a99355f6977f946398b0a94a
In order to support automatically updating the release notes when
we create stable branches, we want the pages to be in a standard
order. This patch updates the order to be reverse chronological,
so the most recent notes appear at the top.
Change-Id: Iddc12f8c0bef847d3b3a45c05fedcb64bb2be2a1
Original problem is that dhcp_release does not work with IPv6, but IPv6
leases still should be released. For example:
1. Start VM in dhcpv6-stateful network, make it acquire IPv6 address.
2. Delete VM.
3. Start another VM in same network before lease expires.
There's a very high chance that the same IPv6 address will be allocated
for both of these VMs (same address will be reused after first VM was
deleted).
On DHCP agent, hosts file would be changed, but not lease file, so
dnsmasq will not give second VM address until lease expires. Reducing
lease time is not a good solution here.
Solution is adding invocation of dhcp_release6 utility when
releasing IPv6 address. dhcp_release6 utility appears in dnsmasq 2.76.
It crafts DHCP6_Release packet, sends it from passed network
interface to IPv6 multicast address and waits for DHCP6_Reply.
Closes-Bug: 1521666
Change-Id: I5efab81cdaf0676503b6c7da0d4b4f400d859286
In L2 agent extensions, when the agent extension needed access to a
datastructure within the L2 agent, an agent extension API object was created.
This API object would be the interface permitting agent extensions to have
access to those objects internal to the L2 agent.
This change implements a similar agent extension API object for the L3 agent
extensions. This is necessary to allow L3 agent extensions to have access to
the RouterInfo class, so that they can do lookups on it, for example
determining the namespace for a specific router. Without this API object, the
L3 agent extension would not have access to this structure.
Co-Authored-By: Margaret Frances <margaret_frances@cable.comcast.com>
Partially-Implements: blueprint l3-agent-extensions
Change-Id: I85f89accbeefd820130335674fd56cb54f1449de
Remove number of vf validation from scan_vf_devices method
in the eswitch manager module, to allow the SR-IOV agent
to load when using PF passthrough.
Closes-Bug: #1614086
Change-Id: Iff5bf3a5542d5b19f45637e954a72a14402a30ae
This patch adds SR-IOV agent driver, which uses eswitch manager, to set
VF min_tx_rate parameter. This parameter defines the guaranteed minimum
bandwidth for egress traffic.
DocImpact
Partial-Bug: #1560963
Change-Id: Iefe5e698e99d186202d6ef170f84e93bfbba46dd
This patch introduces the front end implementation for QoS
minimum bandwidth rule.
APIImpact: New type of parameter for QoS rule in neutron API
DocImpact
Change-Id: I6b619a96a2bfde164646c71409b671352bc6ce7d
Partial-Bug: #1560963
There is no technical reason to disable sorting and pagination, except
maybe performance concerns. But there are other ways to DoS-attack
neutron-server services, like... any other type of request. So the
concern is moot.
Keeping those options available for configuration reduces compatibility
between Neutron installations. It's better to do the right thing, and do
it right, implementing the feature for the benefit of API users.
DocImpact Update configuration documentation to reflect deprecation.
Change-Id: Iad26221a58589b10381f1a0d69a88c92fb5adeee
Related-Bug: #1566514