1. Make grenade jobs experimental for EM branches
As discussed in ML thread, we are going to
make grenade jobs as non voting for all EM stable and
oldest stable. grenade jobs are failing not and it might take
time to fix those if we are able to fix. Once it jobs are
working depends on project team, they can bring them back to
voting or keep non-voting.
If those jobs are failing consistently and no one is fixing them
then removing those n-v jobs in future also fine.
Additionally, it was proposed in neutron CI meeting  that non-voting
jobs would be moved to experimental, so move grenade jobs there instead
of keeping them non-voting
(cherry picked from commit 9313dce459)
2. Install pip2 for functional/fullstack/neutron-tempest-iptables_hybrid
Else both jobs fail with "sudo: pip: command not found"
3. Add ensure-tox for functional/fullstack/neutron-tempest-iptables_hybrid
Similar error message for tox
4. Disable OVS compilation for fullstack and move job to experimental
Compilation fails similarly to recent master failures:
/opt/stack/new/ovs/datapath/linux/geneve.c:943:15: error: ‘const struct ipv6_stub’ has no member named ‘ipv6_dst_lookup’
But branch 2.9 is not updated anymore. Use official package
This triggers a few tests failures, so move it to experimental (instead
of marking non-voting), same as grenade jobs
Kernel 4.4.0-145 backported a change on IPv6 fragmentation API, so
update the OVS version checked out for fullstack tests to a hash
including the needed compatibility layer changes
This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.
This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.
This update should result in no functional change.
For more information see the thread at
Enforce validation on filter parameters on list requests.
If an API request contains an unknown or unsupported parameter,
the server will return a 400 response instead of silently ignoring
the invalid input.
In resource attributes map, all filter parameters are annotated by
the ``is_filter`` keyword. Attributes with is_filter set to True
are candidates for validation.
Enabling filter validation requires support from core plugin and
all service plugins so each plugin need to indicate if it supports
the validation by setting ``__filter_validation_support`` to True.
If this field is not set, the default is False and validation is
turned off. Right now, the ML2 plugin and all the in-tree service
plugin support filter validation. Out-of-tree plugins will have
filter validation disabled by default.
An API extension is introduced to allow API users to discover this
new API behavior. This feature can be disabled by cloud operators
if they choose to do that. If it is disabled, the extension won't
Functionality is added to the ML2 plugin to handle multiple port
Co-Authored-By: Anindita Das <firstname.lastname@example.org>
Co-Authored-By: Miguel Lavalle <email@example.com>
In before, filtering of AZs is using the filter implementation of
agents. To filter the AZs, users need to find the AZ fields to filter,
locate their corresponding fields in agent, and compile the filters
based on the mapping between AZ and agent. This is undesirable.
This patch improve the filtering of AZ by converting the AZ filters
to agent filters. The supporting AZ filters are:
* name: the name of the availability zone
* state: the value is either 'available' or 'unavailable'
* resource: the value is either 'network' or 'router'
NOTE: For backward-compatibility, the old filters still works but
its usage is discourage.
APIImpact: Add filters to specify attributes of availability zones
Ensure that host routes are maintained for each subnet within
a network. Subnets associated with different segments on the
same network get host_routes entries added/removed as subnets
are created, deleted or updated.
This change handle the host_routes for the peer subnets on the
same network when a subnet is created or deleted.
Also adds a shim api extension.
APIImpact: Host routes are now calculated for routed networks.
Passing 'null' (None) as the mac address in a port update
request causes the port's mac address to be re-generated
using the base MAC address Neutron uses for VIFs.
This change implementes a temporary lib api definition
with a new converter that will generate valid mac if the
data provided is None.
APIImpact: Port mac_addr regenerated if None passed on update.
In commit  openvswitch firewall driver is switched to be
default one used in devstack.
So various tempest jobs will use this driver and it will be
We now need separate job to test non-default firewall driver
which currently is iptables-hybrid driver.
In some test jobs, like fullstack and ovsfw-scenario job
openvswitch kernel module is compiled from source before tests.
This compilation was failing because of new kernel 4.4.0-127 provided
Kernel module will be compiled from source which contains
fix for this change in kernel.
See related openvswitch commit message for details:
As current Ubuntu uses ovs 2.9.0 we don't need to compile ovs for
ovsfw-scenario-job anymore because fix we needed is already contained
in ovs 2.9.0.
This will enable users to filter list of results with attributes
with empty value. For example, the request below will list
all unbound ports (unbound ports have blank device_id).
The tag and tag_ext extensions are deprecated for removal, but are not
used widely today . Rather than rehoming these extensions to
neutron-lib and carrying out their deprecation life-cycle for no
apparent reason, this patch proposes we just remove them now.
While  initially removed these extensions, we had to revert
them with .
It looks that many scenario tests are failing because of too long
instance booting time and reached ssh timeout during checking
So longer timeout should solve this problem and tests should
not fail with this reason.
It looks this patch breaks Zun's gate. The reason might be
that Zun depends on Kuryr-libnetwork which still use the
legacy tag extension. I propose to revert this for now and
give the kuryr team some time to migrate to the new extension.
This reverts commit 38148d1752.
This patch allows users to filter ports depending on security groups.
In addition to that I added a unit test to verify this change.
TODO: move security_groups_port_filtering_lib.py into neutron-lib.
We still run API tests agains logging API and the job has OVS enabled.
As all linuxbridge flavors contain same string, this patch changes when
logging service plugin is configured which is always but in linuxbridge
Current implementation of the agent l2 extension is not compatible with
linuxbridge. More work should happen before it's possible to enable it
Neutron currently supports filtering ports by matching the exact
IP address. This patch adds support for substring matching using
"LIKE" SQL operator.
This patch also added a new API extension to show whether or not
the substring matching capability is available.
APIImpact add IP address substring filtering on listing ports
Co-Authored-By: Zhenyu Zheng <firstname.lastname@example.org>
lib/neutron doesn't configure for gre by default, so we need to set the
range of tunnel ids ourselves if we ever want to switch to the new
New os-testr uses stestr under the hood, which creates .stestr but not
.testrepository directory in the current dir. Other than that, it
doesn't seem like there is any difference in the format or names of
files generated in the directory.
This patch adds ``net-mtu-writable`` API extension that allows to write
to network ``mtu`` attribute.
The patch also adds support for the extension to ml2, as well as covers
the feature with unit and tempest tests. Agent side implementation of
the feature is moved into a separate patch to ease review.
DocImpact: neutron controller now supports ``net-mtu-writable`` API
APIImpact: new ``net-mtu-writable`` API extension was added.
This test has been disabled since .
But it seems the failure ratio is not so high with
the current code. Let's re-enable it now and see how it goes.
Note: This same test has been enabled on the gate jobs for
other implementation for a while. It doesn't fail much there