This commit adds opendev.org/openstack/cyborg-tempest-plugin to
required-projects to pass the plugin-sanity-check job. It's a new
tempest plugin. It doesn't work properly on master yet. So, I put it on
the BLACKLIST.
And this commit also removes octavia because octavia tempest tests were
already migrated to octavia-tempest-plugin, and there is no tempest test
in the octavia repo. The removal patch[0] in octavia was already merged.
[0] https://review.opendev.org/#/c/659516/
Change-Id: Ied13dbf774472e1c36dca4ccca157104a81fbf9d
This commit removes airship-tempest-plugin entry from the BLACKLIST
since the patch was already merged. And airship/tempest-plugin has a
gate job to verify it, too. There is no reason to store it in the
BLACKLIST anymore.
And this commit also make plugin-sanity-check's basepython python3
because we should use it as a default.
Change-Id: I9c50d327df65fecf8510f6f54f06e9f42da9bea0
The test doesn't take into account that the interface can
already be associated with the IP address, configured by
NetworkManager. Therefore the review adds a check if the
IP is already set.
Change-Id: I4eede97c041b44d9a7bb754e5ccc1ebb194a2e4b
This reverts commit e3e7b2722e.
After that change, if the test creates a volume type with a
given name, it's not unique and therefore can hit a 409 conflict
trying to create a volume type with a name that already exists,
which can happen when running scenario tests concurrently since
several encrypted volume tests use the same volume type name "luks".
See Iecf62d411d2da17c4c983915018e3ed9180ecd11 for an
alternative but this is easier. It's not entirely clear
why the original change was made anyway - why do we care
if the tests create long names? They weren't unnecessary
because they were random to avoid conflicts.
Change-Id: I9f5a967514f3c79f861d286f65402e9ec2832cc4
Closes-Bug: #1826953
When deleting security group before vm is deleted, we will get 'the
security group is in use' error, so this is to add addCleanup to ensure
the vm is deleted before deleting security group.
Closes-Bug:#1826301
Change-Id: I3d4a3816196f42af3ea3f891473d09208651ae68
This change introduces a true cinder host to host attached volume
migration test in addition to the existing attached volume retype test.
To enable this two new calls are introduced to the v3 volume client to
allow all volume backends to be listed per project and to also call for
a direct volume migration between backends.
Related-bug: #1803961
Depends-On: I1bdf3431bda2da98380e0dcaa9f952e6768ca3af
Change-Id: I501eb0cd5eb101b4dc553c2cdbc414693dd5b681
In test_update_default_quotas, we should use show_quota_class_set
after update_quota_class_set to check whether the quota values
are really changed.
Besides, some LOG messages look odd and maybe being used as comments
are more suitable.
Change-Id: I05e22c88e184df7d425411051c2a8bf846cb35ee
Previously only the volume type and timestamp data was checked when
retyping an attached volume. This change adds additional assertions to
ensure the volume state remains `in-use`, volume migration state is
`success` and the same `volume_id` remains attached to the instance
after the retype completes. This final check ensures that nova has
correctly called the os-migrate_volume_completion cinder API.
Related-bug: #1803961
Change-Id: I32f0611bdfd2ccede73e7ab774286f5315ff92c3
When I specified COMPUTE_MICROVERSION = 2.53,
the error message made me confused. It doesn't
tell me whether the type I set is int or a string,
so I recommend adding a type check.
Change-Id: I620c90f1652fa22bff2ffff9b84b1addc31285ff
display_name is not a valid filter for list_volumes, i.e., for non-admin
users no matter what value we set for display_name filter, all volumes
will be returned. We'd better to use name filter for it works all the
time.
https://github.com/openstack/cinder/blob/master/doc/source/admin/generalized_filters.rst
Change-Id: Ib25f4767b74d4494edfafa211d5884a01c1b6488
This decorator can be used to temporarily mark some tests as unstable.
This may help sometimes to debug such test which is failing often
but not always in the gate because it will still be run but will
not cause all job failure when it fails.
This may be also used to easily track in logstash how often
such test is failing by looking for describption of unstability
reason set in decorator.
Change-Id: I79ce70f479506ec2b3216747d533ff2e450685aa
Related-Bug: #1813198
This test is very unstable and failing very frequently now a days
19 fails in 24 hrs / 137 fails in 10 days
- http://status.openstack.org/elastic-recheck/#1483434
Let's skip this until bug is fixed to avoid unstable gate.
Related-Bug: #1483434
Change-Id: Id107766126b31028920092ab098b084557d327cf
I don't see any limitations by using pre-provisioned
credentials for these tests:
* test_role_create_update_show_list
* test_list_roles
* test_implied_roles_create_check_show_delete
* test_roles_hierarchy
* test_assignments_for_implied_roles_create_delete
* test_domain_roles_create_delete
* test_implied_domain_roles
* test_assignments_for_domain_roles
* test_list_all_implied_roles
* test_grant_list_revoke_role_to_user_on_project
* test_grant_list_revoke_role_to_user_on_domain
* test_grant_list_revoke_role_to_group_on_project
* test_grant_list_revoke_role_to_group_on_domain
By setting force_tenant_isolation=False these tests now be
can executed with backends that don't allow user creation
(immutable user source) like LDAP.
Partial-Bug: #1714277
Change-Id: Id82f3b6187e878abe04a0aea9e7dbb9e8fb6360e
Previously the only clean up action registered when creating a new
volume type was the direct removal of that type. However this request would
silently fail in the attached volume migration scenario tests if the
backends being used had their image volume cache enabled.
This was due to the image volume cache still containing volumes
associated to the given volume type when attempts were made to delete
the volume type. To avoid this these image volume cache volumes must be
manually removed by an admin user before deleting the volume type.
Closes-Bug: #1823880
Change-Id: Ib4d82586e91037729f9e846a6f0fac6d393ca475
currently we do not run the gate jobs if any change is for
test|requirements.txt only which can break the things.
Example- https://review.openstack.org/#/c/649804/
Because Tempest does not have functional testing which might
be enough for teting the requirement change, we start running
the all gate jobs for such change.
Change-Id: I54384f5c664673ef32937cd1d7c4a46c10c18f9b
We have jsonschema capped at a fairly old version. Other than some
specific releases, it looks like keeping it below 3.0 was added in
I943fd68b9fab3bce1764305a5058df5339470757 without really any explanation
why.
In order to update to a 3.x release we need to:
1. Remove the cap from global-requirements.txt (see Depends-On), leaving
upper-constraints.txt at a 2.x release
2. Remove the cap from all consumers (this change)
3. Release a new version of consumers that are published to pypi
4. Update upper-constraints.txt with those new releases
5. Update jsonschema in upper-constraints.txt to a 3.X release
(See: https://review.openstack.org/649789)
6. Test consumers with the change from 5.
7. [Optional] fix issues in consumers that arise from 6.
8. Merge the change from 5.
Change-Id: I95b5520ca0e8da7b2a7663a272bc740b8c809592
Co-Authored-by: Sean McGinnis <sean.mcginnis@gmail.com>
Depends-On: https://review.openstack.org/649669
Nova change https://review.openstack.org/572790/ is fixing
a bug such that the compute API would allow people to
swap from a multiattach volume with multiple read/write
attachments, which could lead to data loss if the
secondary attachment is writing to the source volume while
it's being copied to the target volume.
As a result, test_volume_swap_with_multiattach needs to be
changed such that the volume we're swapping from has only
read-only attachments.
Change-Id: Ida387c600016b451e01118bc2c76662b46670288
Related-Bug: #1775418
Improve logging in tempest cleanup when a router and
its interfaces are being deleted. The review adds a
try except block for every attempt to remove a port.
By that addition any port error will not be hidden
behind the router error the port is attached to.
It will provide more precise error logging.
Change-Id: I475deec7b29600627f68ff07c5546e55cdab100f