oslo_service 0.10.0 release added register_opts function to wsgi
module that is why it is no longer needed to access its private
_options module.
Change-Id: I4803a3540a6bc9c8f08db49e209668d0736abec7
Depends-On: Id0f9f93758c68aa954d37e3566e35deae2961268
Remove disable_service from configure_for_func_testing.
A recent Devstack patch (Linked in bug report) checks
that a disabled service is not enabled later. This breaks
the code this patch touches. I believe the DBs were disabled
and enabled with the assumption that Devstack expects only
a single DB to be configured at a time, but that doesn't
seem to be the case. Simply removing the disable calls seems
to work fine.
Also exclude oslo.messaging==2.6.0 as per global-requirements.txt.
Closes-Bug: #1505259
Closes-Bug: #1505295
Depends-On: I47ab12f719fba41c2f0c03047b05eb28f4423682
Change-Id: I0fbcc1218e1aa9adbf89f6121c1c2e224ed93cab
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
Return a list of currently enabled API versions building
the response in the same way as it is done for the eventlet
WSGI API in order to ensure backward compatibility.
The only version listed is obviously 2.0, but the solution
devised in this patch allows version controller for self
declaring the version they implement.
This patch also replaces the use of _lookup when such method
is not strictly necessary.
To this aim, the minimum version of Pecan has been bumped to
1.0 as previouse releases did not support dots "." as valid
characters in URI path segments.
Change-Id: Ia748194b2c07a04a711d32ce8058a006e73621ef
Note to reviewers: gerrit diff for merge patches is very limited, and
leaving comments in global section won't scale, so please comment here:
https://etherpad.openstack.org/p/qos-merge-back-review
This merge commit introduces QoS feature into Liberty release of
Neutron.
The feature is documented in: doc/source/devref/quality_of_service.rst
included with the merge patch.
It includes:
- QoS API service plugin with QoS policy and QoS bandwidth limit
(egress) rule support;
- core plugin mechanism to determine supported rule types, with its ML2
implementation;
- new agent extension manager;
- QoS agent extension with pluggable backend QoS drivers (Open vSwitch
and SR-IOV support is included).
To extend network and port core resources with qos_policy_id attribute,
a new ML2 extension driver (qos) was introduced that relies on the QoS
core resource extension (the idea is that eventually we'll get a core
resource extension manager that can be directly reused by core plugins).
Agent-server interaction is based on:
- get_device_details() method that is extended with qos_policy_id;
- a new push/pull mechanism that allows agents and servers to
communicate using oslo.versionedobjects based objects sent on the
wire.
The merge includes the following types of test coverage:
- unit tests;
- functional tests for OVS agent, QoS agent extension, and low level
ovs_lib changes;
- API tests to cover port/network qos_policy_id attribute and new QoS
resources.
The client changes can be found at:
* https://review.openstack.org/189655
* https://review.openstack.org/198277
The team also prepared fullstack test but it needs to wait for client
merge before it can pass in the gate:
* https://review.openstack.org/202492
Gerrit does not show diff for merge changes that did not result in any
conflict, so to facilitate review, rely on the following steps:
- fetch the patch locally
- git fetch origin
- git diff origin/master...
This merge also disables qos extension API tests until the service is
enabled in master gate.
Local changes apart from conflicts:
- updated down_revision for qos migration to reflect master expand head;
- disabled qos API tests with gate_hook.sh until we have it enabled in
master gate;
- bumped oslo.versionedobjects requirement to reflect what is in
openstack/requirements' global-requirements.txt
DocImpact
APIImpact
Partially-Implements: blueprint quantum-qos-api
Partially-Implements: blueprint ml2-qos
Partially-Implements: blueprint ml2-qos-ovs-bwlimiting
Partially-Implements: blueprint ml2-sriov-qos-with-bwlimiting
Change-Id: I92916d0e391791187e9a25ff172fb4b3504857b1
This patch is the initial work for the pecan refactor.
* Adds pecan as a requirement
* Adds a simple API server named 'neutron-dev-server' for use
when neutron server is not deployed in a web server
* Wraps the app with the openstack request ID middleware
* Adds a basic V2 controller that breaks out requests by method
* Adds functional tests to ensure request ID is set and requests
are properly sent to the V2 controller.
Partially-Implements: blueprint wsgi-pecan-switch
Co-Authored-By: Brandon Logan <brandon.logan@rackspace.com>
Co-Authored-By: Mark McClain <mark@mcclain.xyz>
Change-Id: Ic9697ff30ab8359b62ce01eb73dc927065a8e3e6
Also applied the following fixes:
===
1. cleaned up some pylint failures that were not spotted before:
Module neutron.objects.qos.policy: Metaclass class method __new__ should
have 'mcs' as first argument
Module neutron.objects.qos.rule: Lambda may not be necessary
===
2. Revert "Introduce the AFTER_READ callback for ports and networks"
This reverts commit e3dba1424114575581c153e02227282e036ad0a2.
We don't use callbacks to extend resources anymore, instead relying on
ml2 extension drivers. No need for the patch to achieve QoS, and it also
breaks test_delete_subnet_with_callback that was added in master
recently.
===
3. updated requirements.txt and test-requirements.txt based on:
https://review.openstack.org/#/c/204398/
to avoid requirements gate checks failing due to incompatible
requirements comparing to global-requirements.txt
Change-Id: I744ab2d8327a428a5467f2d07d073a5f8c333520
Well, first versioned objects in the tree.
Binding to networks and ports is not implemented.
No tests. Checked manually.
blueprint quantum-qos-api
Co-Authored-By: vikram.choudhary <vikram.choudhary@huawei.com>
Change-Id: I9b6cacfda4f40230d746222bed5b6c490be63743
Commit 276028cca26af573c14938255e40c58358eabd4a added these
requirements to setup.py from a custom build hook. These requirements
can now be expressed in requirements.txt. We need to move them there
so that the global requirements sync job can continue to keep setup.py
in sync with the global version.
Depends-on: I2369971d306c10dc39a1b89698cec95cf7551d07
Change-Id: I3c07c279d33f6aed46c3a97dd9ba81251e51429a
oslo.service has graduated, so neutron should consume it.
Closes-Bug: #1466851
Depends-On: Ie0fd63f969f954029c3c3cf31337fbe38f59331a
Depends-On: I2093b37d411df9a26958fa50ff523c258bbe06ec
Depends-On: I4823d344878fc97e66ddd8fdae25c13a34dede40
Change-Id: I0155b3d8b72f6d031bf6f855488f80acebfc25d4
This patch takes the latest global requirements update from change
Ibcb49412a012f79be2f7fd697349ddbf43bd7b9b except takes out the update
to setup.py which reverts the windows specific requirements. We are
still working on getting the custom changes out of setup.py in change
I3c07c279d33f6aed46c3a97dd9ba81251e51429a.
Change-Id: Iee7612d39b520cf04e3b2ec503ec79d23f15f949
Since we can't merge proposal bot at the moment, due to a conflict with
setup.py, at least get our reqs files up to snuff.
Change-Id: Ie313c81502dfe17a4afdcfdba4e207b9866e1399
Some non intrusive changes to tests are needed, so that we don't rely on
library symbols that are now private (f.e. parse_rule).
Closes-Bug: #1458945
Change-Id: I90326479e908042fec9ecb25fa19a8dd5b15e7d8
get_admin_roles was introduced so that contextes generated from
within plugins could be used for policy checks. This was the case
up to the Havana release as several plugins invoked the policy
engine directly to authorize requests.
This was an incorrect behaviour and has now been fixed, meaning
that get_admin_roles is no longer need and can be safely removed.
This will result in a leaner and more reliable codebase. Indeed the
function being removed here was the cause of several bugs where the
policy engine was initialized too early in the server bootstrap
process.
While this patch removes the feature it does not remove the
load_admin_roles parameter from context.get_admin_context. Doing so
will break other projects such as neutron-lbaas. The parameter is
deprecated by this patch and an appropriate warning emitted.
As a consequence neutron's will now no longer perform policy checks
when context.is_admin=True. This flag is instead set either when
a context is explicitly created for granting admin privileges, or
when Neutron is operating in noauth mode. In the latter case every
request is treated by neutron as an admin request, and get_admin_roles
is simply ensuring the appropriate roles get pushed into the context
so that the policy engine will grant admin rights to the request.
This behaviour is probably just a waste of resource; also it is not
adding anything from a security perspective.
On the other hand not performing checks when context.is_admin is
True should not pose a security threat either in noauth mode or
with the keystone middleware. In the former case the software keeps
operating assuming admin rights for every requests, whereas in the
latter case the keystone middleware will always supply a context
with the appropriate roles, and there is no way for an attacker
to trick keystonemiddleware into generating a context for which
is_admin=True.
Finally, this patch also does some non-trivial changes in test_l3.py
as some tests were mocking context.to_dict ignoring the is_admin flag.
Closes-Bug: #1446021
Change-Id: I8a5c02712a0b43f3e36a4f14620ebbd73fbfb03f
This is needed for vendor libraries out of tree to start switching their
code to oslo.log logging interface. Hopefully, they will be able to run
against neutron core using neutron.openstack.common.log while executing
oslo_log.log.* calls.
Change-Id: I666389efe65526bda66c5f70170687638d1a5038
Related-Bug: #1425013