run-tempest is changed recently to add the new variables but
keep supporting the old ones too, for example:
tempest_black_regex, tempest_exclude_regex. and if both
old and new var are used in job definition (parent and child) then
new variables are picked. Because Tempest is branchless, zuul pick
the Tempest master playbooks/roles. That is why job running on stable
branch gate will pick the base job definition from Tempest master.
This way if any stable jobs which were defining the old var and using old
Tempest are broken if any of their parent job define the new var.
This commit pin the older run-tempest role for such stable branches.
Change-Id: If49ab0c31aca5b7837636727096a9bc83f891b1b
Derive the job from the py3 version of the multinode base job,
otherwise several definitions are lost.
The more visible symption of this issue is the wrong usage of
USE_PYTHON3=False when the job is used on stable/ussuri.
Closes-Bug: #1935956
Change-Id: I603f952f18851828ca681ddcc82c54c4d2fe66e6
This patch makes sure that the test cleans up properly
default security group which gets created with the
new project from the setUp function.
Before, the test deleted only project and left the
security group unremoved.
The reason why the project is created in setUp function
is explained in [1][2].
[1] e094bbade2
[2] https://bugs.launchpad.net/tempest/+bug/1789938
Change-Id: Ie7381ee1a90fa8e075ca246c065eaec3c92e1092
Closes-Bug: 1925132
Co-authored-by: Aleksey Myltsev
Volume tests had hardcoded value (1) in case they were creating
a second volume with a different size than the first one
(CONF.volume.volume_size). This is a problem for systems which
have a chunk size other than 1. The patch is adding a new opt
CONF.volume.volume_size_extend which allows customization of an
extended volume size.
Closes-Bug: 1917299
Change-Id: Ic8ae486224cd2a470f4f9bbad62d4d6715cc63ac
For 'domain' and 'system' scoped token, there is no project_id
so we cannot create the network which need project id as one of
the parameter.
In Xena PTG[1], we have discussed about project mapped resource
creation/managing with system token
- L77-140 https://etherpad.opendev.org/p/nova-xena-ptg
- https://etherpad.opendev.org/p/consuming-system-scope
Once we sort out the network ceration or need for system, domain
scoped token then we can update the newtork creation in Tempest.
Change-Id: If6ae6465369c9018c716d48555fd99fc90ce0e59
A new configuration option volume_type was added to tempest.conf
to allow tempest users to select volume type during volume creation.
In this patchset, this volume_type value is used if configured for
compute api volume creation.
Change-Id: I031094ab196268dc2c20b38be4864f59639358a7
Attribute "active" is going to be added to the allowed_address_pairs
in the patch [1] and will not be available in older branches.
To make our existing allowed_address_pairs API tests to be passing in
both cases, with and without that "active" attribute, this patch
removes that field from the allowed_address_pairs which are returned
by the Neutron server.
We could make expected results of those tests to be dependend on the
available Neutron's API extensions but in that case existing tests may
fail randomly as all tests are always using same IP addresses thus
allowed_address_pair may be active=True or active=False.
To properly check active/inactive allowed address pairs there will be
additional tests added to the neutron-tempest-plugin in the follow up
patch.
Similar change is also proposed to the neutron-tempest-plugin in [2].
[1] https://review.opendev.org/c/openstack/neutron/+/601336
[2] https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/794788
Related-Bug: #1928466
Change-Id: I9e3eb3cc06c0a10a48d9309a183b14eda210d40f
Swift is ready on py3 since stable/ussuri and we enabled
it in tempest-full-py3 job for stable/ussuri onwards.
This commit does the same for tempest-slow-py3 job also so that
we can run swift slow test in this job.
Change-Id: I7fa41d4272f792d6fd00bece202c44e342dfeb0a
from Tempest to DevStack as it tests DevStack side of things and
is useful for projects not using Tempest.
This is part 2 of 2.
The 1st part is DevStack-side, in Depends-On.
The script is left calling out to devstack because legacy (dsvm)
jobs rely on its presence.
Depends-On: Ie166730843f874b9c99e37244e460d7ad33b7eeb
Change-Id: I6fa17ae413f106453303c4882925573bd8e05029
We have many job definition version for stable and master
gate and those are in same file integrated-gate.yaml. This
create confusion while modifying these jobs for master and
can end up modifying stable version.
Example: https://review.opendev.org/c/openstack/tempest/+/794312
Keeping all stable job definition in stable-jobs.yaml will help
us to accidentally modifying the stable jobs definition.
Change-Id: I44ae4a4b7070dd44f50070ad24e9d33f417ae955
When we created the separate definition for tempest-full-py3 job
for swift enable on ussuri onwards, we missed to add the
few configutation like horizon, networking config due to rebase
and all
- I63159e5e8c0c8b6751ea481577b4c4637a7f25b5
This commit re-add all those configuration back to job version
of ussuri onwards.
This issue is found when we saw horizon dashbaord test is skipped
in tempest-full-py3 master gate.
- https://zuul.opendev.org/t/openstack/build/34892e0fd92f410bb99b37c8fe2e5255/log/job-output.txt#27738
Change-Id: I9602937f53933a9d30022512b7fe6a817d7e6472
Cinder decided to remove the v2 APIs[1] in Xena cycle, so
in Tempest we need to modify the tempest-cinder-v2-api job
to run against stable wallaby which is last release where
volume v2 APIs are present.
Also ad deprecation warning at v2 service clients module level
import so that we can remove them once Tempest stop supporting
stable wallaby.
NOTE: we do not need to adjust any tests as we already moved all
the Tempest tests to volume v3 APIs.
Depends-On: https://review.opendev.org/c/openstack/devstack/+/791842
[1] https://wiki.openstack.org/wiki/CinderXenaPTGSummary#Removing_the_Block_Storage_API_v2
Change-Id: I98339f67239cf96d26aa4fa87df692139b36673d
Glance has removed the image v1 APIs in Victoria
cycle: https://review.opendev.org/c/openstack/glance/+/738673
Tempest still support Ussuri release which is last release
where image v1 APIs are present so we need to keep them until
stable ussuri is supported in Tempest but we can deprecate them.
Change-Id: Iabc02c4516c84b523c61b82a2a44ee0db73f21e4
Cinder has removed the volume v1 APIs in queens
cycle: I03bf2db5bd7e2fdfb4f6032758ccaf2b348a82ba
Tempest does not support queens release so we are good
to remove the volume v1 service clients also.
Change-Id: I297f230de51e0ef4f35eb33ddbaaab53c230713f
Creating an encryption-type without key_size or cipher results in
a useless volume type that cannot be built, but this only becomes
evident later when the volume type is used. The Block Storage API
is adding validation to make sure these fields are specified at the
time of encryption-type creation to avoid this situation.
The current test_volume_type_encryption_create_get_update_delete
creates a not-fully-specified volume type, which should not be
allowed, so update the test.
Change-Id: I3c8c5a5261e135bcf56cfa5624ee1a504f31bdf3
Related-bug: Bug #1926630
Add a method to return the current resource usage for a specific
resource provider. Given a specific rp_uuid return the resource
providers current generation as well as its assoicated resource class
usage at that time. Example output below:
(Pdb) self.resource_providers_client.list_resource_provider_usages('90234521-0f4f-4777-98d8-731db8e61a0d')
{'resource_provider_generation': 52, 'usages': {'VGPU': 1}}
More details of the api can be referenced here [1]
[1] https://docs.openstack.org/api-ref/placement/#resource-provider-usages
Change-Id: I13ca77f1cd8fbf74cd716b2d8eae772f5328a4d4
Once Glance finish the import operation(change image status
to active), it move the task to 'success' state but in between of
image become active and task is transitioning to 'success', tempest
try to check the task status and race condition happen.
Adding waiter method in test for task status check.
Closes-Bug: #1926671
Change-Id: I960b80314f1b0926eca33af830bc827f31cbeda6
Tempest hacking check _common_service_clients_check()
still has the ignored_list_T110.txt file check but this
file was already deleted a long back
- https://review.opendev.org/c/openstack/tempest/+/568489
This fix the pep8 check for service client checks otherwise it
fail on finding the ignored_list_T110.txt file.
Change-Id: I6069d1c2f6368e768640ce69981241792ea81aac
Tempest use stestr to run the tests, adding
a experimental and periodic job to run Tempest
with stestr master will help to detect any
breaking change in advance.
Change-Id: Ice57e193c5150be7141e0e003be5091a191b854c