octavia-tempest-plugin 1.8.0 release

meta:version: 1.8.0
meta:diff-start: -
meta:series: xena
meta:release-type: release
meta:pypi: no
meta:first: yes
meta:release:Author: Ghanshyam Mann <gmann@ghanshyammann.com>
meta:release:Commit: Ghanshyam Mann <gmann@ghanshyammann.com>
meta:release:Change-Id: I401f91c01f5fd72d8bcadd0f1cc2b15f255e2523
meta:release:Code-Review+1: Michael Johnson <johnsomor@gmail.com>
meta:release:Code-Review+2: Elod Illes <elod.illes@est.tech>
meta:release:Code-Review+2: Hervé Beraud <herveberaud.pro@gmail.com>
meta:release:Workflow+1: Hervé Beraud <herveberaud.pro@gmail.com>

All the load balancer service clients are registered via the plugin interface[1],
that way Tempest register and create the lazy initialization of registered clients
so that they can be access from there in consistent way.

But octavia-tempest-client create a separate instance of those and access instead of
accessing the registered service client in Tempest. This commit makes all the service clients
access from Tempest registry and remove the separate objects.

[1] https://github.com/openstack/octavia-tempest-plugin/blob/cac3eefc44afca458692e9dadb539c0cb17dc9e4/octavia_tempest_plugin/plugin.py#L54

Change-Id: Ie24909b49baf2c6a886e2ff711e641e36ffe6b50

It's possible to use the same VIP port for TCP and UDP protocols.
Two listeners: UDP and TCP are being created using the same VIP port.
UDP and TCP traffic validation, both should PASS.

Change-Id: Ie93829be86b8a2442911ce212cdd0bc98237b962

Fix functions and callers where "listener_id" wasn't actually used.

Change-Id: I7ca3b4011918d7047ad9a16306653b9054e36c4a

Move master and victoria jobs to ubuntu focal.
ussuri and train jobs still use bionic.

Change-Id: I4181a989514389ba18ff7874f8f4332f392d1189

This test covers LB "insert HTTP headers" functionality.
It’s a traffic based scenario and validation is done using real HTTP headers
being received on backend side.

Change-Id: I97efd6bcc793e1378356c18209d5345597f39a00

lb_observer and lb_global_observer don't have any meaning when
admin_or_owner policy override in enabled.
This commit disables client creation for those roles and removes their
uses from API tests (the behavior of the owner_or_admin tests are now
similar to their behavior before the introduction of the new RBAC
tests).

Requires the following configuration in tempest.conf:

[load_balancer]
RBAC_test_type = owner_or_admin
member_role = member
admin_role = admin

Change-Id: I2231384933d5974b962a558e8c0b3bffb1140b5a

This patch refactors the RBAC enforcement checks in the API tests.
It also updates those test for keystone scoped tokens and default roles.

Change-Id: I6fad03f5a89c213562918ca258884aac34ba7ce7

The IPv6+TCP+LC scenario test have randomly failed with an incorrect
dispatch. Adding a delay between requests seems to fix this behavior
(shamelessly inspired by the IPv4 LC scenario tests).

Change-Id: I68baab227f844a057f2abf77b295c3af287a333e

octavia-tempest-plugin 1.7.0 release

meta:version: 1.7.0
meta:diff-start: -
meta:series: wallaby
meta:release-type: release
meta:pypi: no
meta:first: no
meta:release:Author: Hervé Beraud <hberaud@redhat.com>
meta:release:Commit: Hervé Beraud <hberaud@redhat.com>
meta:release:Change-Id: Ib7360c05f4f26d04bd01bfc019e6f0ab863305ca
meta:release:Code-Review+1: Michael Johnson <johnsomor@gmail.com>
meta:release:Code-Review+2: Hervé Beraud <herveberaud.pro@gmail.com>
meta:release:Code-Review+1: Ghanshyam Mann <gmann@ghanshyammann.com>
meta:release:Code-Review+2: Thierry Carrez <thierry@openstack.org>
meta:release:Workflow+1: Thierry Carrez <thierry@openstack.org>

octavia-tempest-plugin 1.6.0 release

meta:version: 1.6.0
meta:diff-start: -
meta:series: wallaby
meta:release-type: release
meta:pypi: no
meta:first: yes
meta:release:Author: Ghanshyam Mann <gmann@ghanshyammann.com>
meta:release:Commit: Ghanshyam <gmann@ghanshyammann.com>
meta:release:Change-Id: I011f9be8ae7fbf9fbd638ec769e0fad53531563d
meta:release:Code-Review+2: Hervé Beraud <hberaud@redhat.com>
meta:release:Code-Review+2: Sean McGinnis <sean.mcginnis@gmail.com>
meta:release:Workflow+1: Sean McGinnis <sean.mcginnis@gmail.com>

Change-Id: I00b3e8172c3d90ef7cabb65d588508728ea658cf

The IPv6 VIP subnet used in the tests is created using devstack's
default IPv6 subnetpool.
Devstack ensures that any CIDR from this subnetpool is routable from the
devstack node if the subnet is plugged into devstack's router1.

Change-Id: Iaf3113087a344787add3405208fb229838a56d0b

This patch creates the required pki resources and enables HTTPS
on the test web servers. It sets up port 443 for regular HTTPS and
port 9443 for HTTPS that will require a valid client certificate.

Change-Id: Ib7cee4c8600fd1be4a9d7027d3ca1f413a0b1007
Story: 2003858
Task: 41170

Stein release of Octavia has reached end-of-life (EOL) support [1].
The stable/stein Octavia branch no longer accepts changes.
We can now remove the Stein CI jobs.

[1] https://review.opendev.org/c/openstack/releases/+/772847

Change-Id: I14ab0f8b159fdd0c7e81b94297a57f30260579fa

This patch updates the test server to have a separate port for
HTTPS with client authentication. This will allow concurrent tests
to run using the HTTPS and HTTPS with client authentication ports.
It adds a new parameter "-https_client_auth_port" for the port that
will require client certificates.

Depends-On: https://review.opendev.org/c/openstack/devstack-gate/+/776722

Change-Id: I6d44787f66904409b7f32a5fe576b658b6eb600a

Without a delay it can trigger a "Cannot assign requested
address" warning setting the source port, leading to failure.

Also added a log debug statement when a source port is
being used since it can help with debugging.

Change-Id: Idcc13fdaafb8ffe41710fc3c67f30932725cf66e

The name of the OVN provider job template changed from
ovn-octavia-provider-v2-dsvm-scenario to
ovn-octavia-provider-tempest-release but was not updated
here, fix it so those non-voting jobs will run.

Change-Id: I3159adeae2456c8fecad87bbfb0f526363e7752b

Add new endpoint in test_server application:
- /request prints the client request (method, URL, HTTP version and
  headers) in the payload of the reply
  /request can take a "response_code" parameter (ie,
  "/request?response_code=404"), the server replies with the appropriate
  HTTP response code to the client.

Change-Id: Ibc03f62da06a5bbb93959eac865e5f3f14caa50e

The API test for pool creation has a check to wait for the
operating status of a pool to transition to ONLINE if a
listener has been provided.

The scenario test for pool creation doesn't wait for any
operating status transition after a pool is created with
a listener, and instead always assumes it's OFFLINE.

They should both wait for a transition, since otherwise
drivers that transition to ONLINE quickly, like OVN, can
race and fail the scenario test.

Depends-on: https://review.opendev.org/c/openstack/octavia/+/763530

Change-Id: I9eb3c7ce8af879cd910b06234c99b53670907e49
Story: 2008009
Task: 40659