Combine all variables starting with tempest_tempest_conf_overrides
to give a complete set of configuration to tempest when multiple
different test scenarios are enabled at the same time.
Change-Id: Iba5e061d1682d16c0516249f628f948a20580df8
If the role variable overrides are updated to remove a set of
existing tempest test exclusions, the previous exclusions file
remains on the disk even though it is not use, and not passed
to the tempest command. This is confusing and the file should
not be present unless there are active exclusions in place.
Change-Id: I5d69bf6258a00ade825cd3c746d1443dc1a35120
Previously the os_tempest role had a single variable for
defining the include and exclude lists in order to select the
tempest tests to run.
This works for simple scenarios, where a single service
is deployed and the tests for that service are enabled through
the necessary variables set in user_variables. This approach is
used in openstack-ansible CI / AIO.
More complicated scenarios such as magnum+barbican+octavia, would
create several user_variables files each with conflicting settings
for the test settings. It is possible in this scenario for there to
be no valid tempest tests to run and tempest to fail immediately.
This patch adds the possibility to have many variables defining
the include/exclude lists which have names using a common prefix.
Any variable names matching the prefix are gathered and combined
with the original role default to make extending the test lists
easy to do in an incremental/distibuted way in the ansible variables
instead of having to maintain a single point defining all necessary
tests.
Change-Id: Ie3a9a7be849171af042567ba8a152e5df5d2cb53
These variable names collide with the best name prefix to use when
gathering many variable names into a combined include/exclude list.
Codesearch shows no use of these as overrides and the number of
cases when an override would be needed is small.
Change-Id: Ic64165e41d24ae8dc75061589de84fa57998f03d
More suitable replacement variables have been available for
several releases now so we can remove the deprecated vars.
Tripleo still defines these deprecated variables in several
places but seems to have made no attempt to move to the new
vars, and tripleo is itself now deprecated so we should move
ahead with removal of these vars from os_tempest.
Change-Id: I5a4a90bc963acc8b44caf7eb060b763e0f90a50f
With update of ansible-lint to version >=6.0.0 a lot of new
linters were added, that enabled by default. In order to comply
with linter rules we're applying changes to the role.
With that we also update metdata to reflect current state.
Change-Id: Ifcb6ebfa971e324e447509e50cc7294bddd6a4a0
Although tripleo deprecate master, we still use os_tempest in wallaby
and train lines, and due a design error, we rely on os_tempest master
branch instead of use the appropriate branch, and the removal of
redhat-8.yml file broken these jobs.
We will in the future, use the proper os_tempest branch on these jobs.
Change-Id: Ic2c547d730e900c883685050366e8e307869e6d1
Ubuntu distro installation installs tempest plugins from source.
For this scenario we're ensuring that wheels won't be built as
repo container that should handle wheels build is simply absent in this
scenario.
For the rest usecases we're sticking with our new default to build
wheels.
Change-Id: Id643946edf4b4e21f8420d048ce8293fc40a61fc
We don't support neither redhat 7 nor redhat 8 as of today, so we can
safely clean-up variable files for these distros.
Change-Id: I1225fd75d25c3a06353b46ddb61f989b73a757b6
For all services we do respect service_install_method vairable,
and define 'source' as the default options. At the moment tempest
attempts to follow source path even for distro deployments.
Change-Id: I5256943b5f175cbf46ae36361887dd055e0c52be
This role was shared with tripleo, but that project is now
deprecated so there is no need to carry the cross-project CI jobs
any more.
Change-Id: I73aec0f325708f42bbd0fd07d572fb833e8dfb2c
Add file to the reno documentation build to show release notes for
stable/zed.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/zed.
Sem-Ver: feature
Change-Id: Ia808641ab5446707ec5296dab6198c260b1b4477
With ansible-core 2.13 it tries to substitude package resolution in apt
module.
However git-core is used in Debian as transitional name, but ansible
tries to select it and provide version, which is not correct behaviour.
But since git-core is not really valid anyway, we just replace it
to workaround ansible's imperfectness.
Change-Id: I862e1ea4cef840d1903962181bfc8ec3c5a1e903
This line was introduced by I0230f1a93d16243fc50df79b2d0780e744706c7b
and should already be covered by the distribution_major_version line
above.
Change-Id: Ibffaadb721796d6f657972633d19bdd36e411c52
``floating_network_name`` works well with UUIDs as well.
This change doesn't make any difference when tempest creates public
network.
But when it's not, operator does not set ``tempest_public_net_name``
which leaves ``floating_network_name`` with a defeault value.
In order to fix ``floating_network_name`` behavior for both scenarios,
it should be set to the ``tempest_neutron_public_network_id``.
We do the same thing for ``public_network_id``.
Change-Id: I10e0c49b0d89b9530a523e9db79d5c7aa52359a4
Currently we define fixed_network_name only when
tempest_create_isolated_networks == False.
It makes things complicated because tempest_create_isolated_networks is
applicable only when dynamic credentials are used.
fixed_network_name should be also defined when dynamic credentials
are not used.
Basically the only scenario when fixed_network_name should not be
defined is using dynamic credentials together with
tempest_create_isolated_networks.
fixed_network_name should be defined in all other cases.
Change-Id: I547d70995de5afbdc84c9f4e86b2599ad4cb100b
For some reason we define a list inside a _tempest_plugins dict.
It should be simplified to the list of dicts.
Change-Id: I891f77e3e22c962615697504d0870e25017511d7
Currently when ``tempest_router_create`` is enabled, playbook requires
``tempest_public_net_create`` to be set.
It's an incorrect behavior. Router creation should only require public
network to exist. It does not matter if that public network was created
by tempest or operator.
Change-Id: Icaa223ed03837a68e9e84a89560cc2df10e3ed3e
The newest openstacksdk is set to rename some of the field names of
return values. This also affects the openstack.cloud collection. This
patch checks for both field names to make sure the os_tempest role
doesn't break when the collections release.
Change-Id: I4b30650a6c78e76982e22746933be7c132490a43
With sphinx release of 5.0.0, they changed default for language variable
to 'en' from None. With that current None valuable is not valid and should
not be used.
Change-Id: If3d84c85f5b439989c2fc7dec0b51068c6fe505a
internalURL is not a valid value for heat plugin, which makes workspace
creation to silenly fail. To avoid that we change default to just
`internal`, that should be supported by all plugins.
Change-Id: I86eef4f4a5cbcd7825488293bb8eaa9c7b9be5f1
Allow to set domain for admin authentication and dynamically provisioned
accounts.
Currently tempest admin user has to reside in the same domain as
dynamically provisioned accounts.
Change-Id: I1d5aa1f32bae42e2eeeed37588f6ca564563e57a
This variable should not be hardcoded.
Setting it to tempest_nova_flavor_id_1 should be a reasonable default.
Change-Id: I11242e55a6925781249afe30f395d16dbeff1c9d
tempest.conf should store configuration only for services installed
in the current environment.
Additionally, I removed empty sections and improved their ordering.
Now service sections are placed at the end of the file.
Change-Id: I43c97758b6db2e5e134d8f54e0911ade3ced8fdf
Tempest currently has two different internal methods for providing
authentication to tests: dynamic credentials and pre-provisioned credentials.
Depending on which one is in use the configuration of Tempest is slightly
different.
We should provide a support for both of them.
https: //docs.openstack.org/tempest/latest/configuration.html#credential-provider-mechanisms
Change-Id: I26d69caa3f96a530bc0a4a21365404b1a84e489a
In most cases, many of tempest resources are not needed.
From the other hand, some of our contributors still need them so we
can't just drop this functionality from this role.
The best solution I see is to add more flexibility and let users
choose which resources should be created by tempest role.
- public network:
new variable: bool tempest_public_net_create (default: true)
if false: require tempest_neutron_public_network_id to be set
if true: require all other tempest_public_net_* variables to be set
explanation: it'd be useful to choose if user wants to use already
existing public net or create a new one/
- private network:
new variable: bool tempest_private_net_create (default: false)
if true: require all tempest_private_* variables to be set
explanation: by default tempest has use_dynamic_credentials &
create_isolated_networks enabled, so it spawns an usable network,
subnet, and router when needed for each project it creates, so in
most cases it doesn't make sense to create special 'private' net.
- router:
new variable: bool tempest_router_create (default: false)
if true: both tempest_public_net_create and
tempest_private_net_create should be enabled
explanation: same case as for private network
- image:
new variable: bool tempest_images_create (default: true)
if false: require tempest_glance_image_id_1,
tempest_glance_image_id_2 to be set
explanation: tempest needs public images, so it'd be useful to just
use already existing ones
- flavor:
new variable: bool tempest_flavors_create (default: true)
if false: require tempest_nova_flavor_id_1, tempest_nova_flavor_id_2
to be set
explanation: tempest needs public flavors, so it'd be useful to just
use already existing ones
- projects:
new variable: bool tempest_projects_create (default:
"{{ tempest_public_net_create or tempest_private_net_create or
tempest_public_router_create }}")
explanation: by default tempest has use_dynamic_credentials &
create_isolated_networks enabled, so we don't need to create any
'static' projects, but network resources spawned by tempest
playbook belong to this project, so it should exist if any of
these resources are going to be created
I don't see any reason why users and tempest role should be created
so i dropped this functionality.
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/825166
Change-Id: Icb46f5cb9e2dda6511cc49e30587f541aa7e399f
We should not include [*-feature-enabled] sections in tempest.conf and use
``tempest_tempest_conf_overrides`` for these customizations instead.
There is no way we can keep feature list updated all the time and cover all
possible features in defaults/main.yml.
That's why I think we shouldn't cover them here at all.
If we need these customizations for testing purposed(tested it and I think we
don't), we should define them using ``tempest_tempest_conf_overrides`` only for
these tests.
Change-Id: If7d7ca5ae76cb3cb24f95fb9608ce3e1182d5e5a
Depends-On: https://review.opendev.org/c/openstack/openstack-ansible/+/825166
likui
OpenStack Release Bot