This reverts commit 318d629308287c199ff937c1b4923a09a56f2984.
Reason for revert: Fix both for networking-bagpipe and networking-bgpvpn are merged now.
Depends-On: https://review.opendev.org/c/openstack/networking-bagpipe/+/883064
Change-Id: I8dbc6e812c1a6fbe57a86827b3b9755bbd2eeee8
In all cases where we are using nc_client, we rely on the messages
returned there in stdout and we don't really check exit_status codes.
It seems that e.g. ncat provided by RHEL 9 returns error_code=1 in case
when connection was refused. And that is expected thing e.g. in some
parts of the port_forwarding related tests.
To avoid unexpected failures due to ShellCommandFailed error we
shouldn't check exit_code there and always return messages from
nc_client's stdout to assert them in the test.
Closes: rhbz#2210233
Change-Id: I17cebaa34acb0dd6c60bd106eb70656faaebbb04
It seems that using "Zero-I/O mode" ("-z" option) in nc client is
necessary for the UDP tests but it is causing failures when it runs it TCP
mode.
Closes: rhbz#2211094
Change-Id: I7d313a7afc60825885854eaa6de858b1f53e5e46
In Linuxbridge and openvswitch_iptables-hybrid jobs for stable/2023.1
and stable/zed branches there was missing definition of the common API
extensions thus list was inherited from master jobs.
Change-Id: I292fd053c7568853f56f7ab39d397889edfe65a4
This job has been unstable for a while on the master
branch, until changes merge lets make it non-voting
in the check queue.
Related-bug: #2020698
Change-Id: I6426a60e01f757f1e97ac698c5cc7abf2b7924d4
When there is a failure and we run commands to collect
network information, the iptables-save command always
fails in the root namespace:
Executing command 'iptables-save' on local host (timeout=None)...
Command 'iptables-save' failed (exit_status=4):
stderr:
iptables-save v1.8.7 (nf_tables): Could not fetch rule set
generation id: Permission denied (you must be root)
Change list_iptables() to always use sudo fixes the issue.
Trivialfix
Change-Id: I656569cb333e98f5f55b51b0cfec8e99922424b3
In the test_qos_dscp_create_and_update API test, qos policy was made as
admin user (which is correct) but was also owned by admin project. And
later, to check if DSCP marking rule was created in that policy
properly, regular client is used instead.
The problem is that with new S-RBAC API policies, rules are visible to
owners of the policy, not to all users. And due to that this test is
failing with new S-RBAC policies enforced.
This patch fixes it by changing owner of the qos policy to the regular
client's project.
Related-Bug: #2018727
Change-Id: Iadf69c167cdda0017084e482a58116520a1ea80f
When stateless SG are used RA packets may be blocked as there is no
stateful connections in SG so it will not be by default accepted
as related to the outgoing RS packets.
To confirm that this works fine, this patch adds new, dual stack cases
for the test "test_default_sec_grp_scenarios". This test is the same as
existing test_default_sec_grp_scenarios for stateful and stateless IPv4
scenarios but additionally checks at the end if IPv6 addresses were
configured properly in the guest VMs.
Change-Id: I1595e5c2072f43e9c8fd7cbfe6fa25815f1ffd92
Depends-On: Id1328d7cba418fa7c227ae9db4fe83c09fd06035
21.03 is no longer supported upstream. We should try to stick to LTS
releases of OVN if possible.
The patch locks the version as the latest git commit in branch-22.03
(ovs is also locked to the corresponding submodule version). This is
done to include a just merged fix for protocols used for ipv6 address
configuration (ra, na, mld*).
Once 22.03.3 is tagged in OVN repo, we can switch to it.
Depends-On: I83fc9250ae5b7c1686938a0dd25d66b40fc6c6aa
Depends-On: I2a633741d5e95f0e46a6b33198903f0f44d449b6
Change-Id: I6d7f6f4fbabc6273b170dfb963a8a37200e9fbc2
This reverts commit 3c30984a53005ed2d7a6a2d37f304bbd631be62d.
All the pending hypervisors are upgraded in
vexxhost-ca-ymq-1 and that fixes the nested-virt
issue.
There is currently mirror issue[1] which is being
investigated but since the vexxhost provider is
disabled[2] we can switch jobs to jammy.
re enablement of vexxhost provider once mirror
issue is resolved shouldn't impact our jobs.
[1] https://bugs.launchpad.net/neutron/+bug/2017992
[2] https://review.opendev.org/c/openstack/project-config/+/881810
Related-Bug: #1999249
Change-Id: I60b7d94da0774558b35794fde522fa82c0259422
This reverts commit 62b7315092318296e23451d956989d672b6a4584.
Reason for revert:
new defaults are enabled by default in current ongoing release cycle which is not yet released so our old defaults is something enabled by default in latest release. Due to that, in devstack we still have them disabled by default[1] which configure all the jobs with old defaults[2], that is why in all the jobs old defaults are enabled[3].
Let's continue testing the old defaults as default and keep this new defaults job until 2023.2 is released. and after 2023.1(2024.1 cycle) we can switch it 1. run all jobs with new defaults 2. a single job with old defaults.
[1] 34afa91fc9/lib/neutron (L96)
[2] 34afa91fc9/lib/neutron (L564)
[3] https://zuul.opendev.org/t/openstack/build/190cdd3f0479408b87dc10c4f9396f10/log/controller/logs/etc/neutron/neutron_conf.txt#2091
Change-Id: I1610f8b13b8fa7567e6f8c41f804ff3b774424e3
Branch stable/xena was transitioned to EM phase already [1] so we don't
need to run its jobs in check and gate queues of neutron-tempest-plugin
repo anymore.
In stable/xena jobs in Neutron and stadium projects we will be running
neutron-tempest-plugin 2.3.0 version which was released when stable/xena
was going to EM phase.
[1] https://review.opendev.org/c/openstack/releases/+/878874
Depends-On: https://review.opendev.org/c/openstack/releases/+/881230
Change-Id: I45cc1a4529b35fff2118ce6278147e1564f74f6b
As nc client's command depends on the nc version installed
it should be checked on the host where it is going to be run.
Before this patch it was always checked on the host where tempest
was running and that could cause some issues e.g. when tempest
was run on RHEL 8/Centos 8 host and Cirros was used for guest VMs.
Change-Id: Ib0ce72a1b622d0f6fcda24f4b78f627092edf639
There is no need to run all scenario related jobs on patches which
touches only files with tests in neutron_tempest_plugin/scenario module.
Change-Id: I0c5a8d240c46372d84a0bdb3ef78ad74dbca75a2
There is a lot of SG rules created in those tests so lets not fail
just due to SG rules quota reached for the test project.
Closes: rhbz#2184349
Change-Id: I717452abeb708fa6007db95a810be3d628b47f39
This patch adds scenario test to ensure that fragmented traffic can be
send properly between VMs which are using stateless SG.
There is no need to add same test for stateful SG as this is already
covered by various tests in neutron_tempest_plugin.scenario.test_mtu
module.
Change-Id: Id07a2bee283c33aeb083e68599faecec467a9844
In stateless SG there is no connection track so TCP packet of any type
should be allowed by SG. This patch adds test which spawns 2 vms,
connected to 2 different networks and the same router. Both vms are
using different stateless SGs. Finally test asserts that packets of any
of the TCP type (syn, ack, syn-ack, psh, rst, fin) sent from one of the
vms can reach second one.
Change-Id: I23a4b282c83101526af05aa309d578aecaef1fa9
This patch extends existing
test_connectivity_between_vms_using_different_sec_groups
in the way that for stateless SG rules it makes sure that replies from
server to client will not work without explicity add SG rule which will
allow ingress traffic on the ephemeral ports' range.
Change-Id: I940678c15b65552634096ea3e72888b5bf830912
This patch adds new test (for both stateful and stateless type of
security groups) which creates: 2 VMs connected to 2 different networks
and using 2 different SGs. Both networks connected to the same router.
Finally it checks TCP connectivity between VMs.
In case of stateless SG additional security group rule needs to be added
to allow ingress traffic on the ephemeral ports' range.
Change-Id: Icf318d8e7a76286ee2c2b8626d80e554aa5289f6
Currently stateless SGs are supported by ML2/OVN backend and by backends
which uses iptables based firewall driver.
It's not supported e.g. by ML2/OVS with 'openvswitch' fw driver thus
those tests should be skipped in case of that backend driver.
Change-Id: I9fa572c3b7eda96706caa2ba1a181de475357804
Create job template for 2023.1 jobs: neutron-tempest-plugin-jobs-2023-1
and fill it with job definitions for all Neutron core and stadium
projects active during the 2023.1 (Antelope) cycle.
Change-Id: I32ebac52b390a150b730e3d23220b24af3bd822b
This scenario test applies stateful SG to the VM, ensures that
connectivity is working fine and then detach SG from the vm, update it
to be stateless, attach again and ensures that connectivity is working
still fine.
Change-Id: I99cf5edf79a77f5940d28fa760e03b66d289be20
test_dhcp_port_status_active is the only missing test in
tempest.api.network.admin.test_dhcp_agent_scheduler.
DHCPAgentSchedulersTestJSON compared to
n_t_p.api.admin.test_dhcp_agent_scheduler.DHCPAgentSchedulersTestJSON.
By moving it from n-t-p we can get rid of the whole module, reducing the
test duplications.
Change-Id: Icbe0b31b44254bc55f52b34ebc5c71ec864307ac
Depends-On: https://review.opendev.org/c/openstack/tempest/+/824440
Previously it was just getting list of SGs and assumed that first one in
the list is the "default" one. It's not always true so now there is
helper method which lists of SGs for project and looks for the one with
name "default" as this name is hardcoded in Neutron.
Change-Id: I608677547c9c8ae00af8821622cefa0955d692c6
Do not use ubuntu minimal image in ussuri scenario jobs.
The minimal image does not have the guestmount package
available, so use the server image instead.
Also had to add an override for designate-tempest-plugin
to address a similar problem that was fixed in the train
template in review:
https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/817465
In addition, to fix the iptables_hybrid job, backport a
change to exclude a security group test that should not run,
test_established_tcp_session_after_re_attachinging_sg,
taken from review:
https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/873708
Change-Id: Iac70ae2b2cb6fe97b96f4d93de19cf08ed144724
This patch is addition to patch [1], in which tests of stateless
security group feature are checking for stateless_sg property,
and adding ingress rule accordingly.
This patch drops extra internal check inside
create_ingress_metadata_secgroup_rule, so it can be used without
dependency in stateless_sg property.
For example:
When testing security group logging integration with stateless
security groups, there will be no need to add specifically that extra
stateless_sg property.
[1] https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/871397
Change-Id: Ic7b021ad262549aee0e4b3ef951791a6d30580b4
