
Scored an existing advisory capability (identity-v3-api-discovery) and made it required in next.json. Scored 3 new capabilities for which I couldn't find tests, adding them however for discussion. One of the new capabilities, identity-v3-catalog refers to the catalog that is returned when calling the current required capability identity-v3-tokens-create. Users may be relying on the catalog to be there, so I think it is worth discussing. identity-v3-list-projects and identity-v3-list-groups are worth discussing and consider for addition of new tests. The rationale for this scoring as well as input from keystone's PTL can be found in working_materials/keystone_capabilities_info.csv. Change-Id: Id444f5e982f2e81f140e285c305e9c322f5b9f42
3.6 KiB
3.6 KiB
1 | Capability | Program | Status | Method | Endpoint | Test available? | interop relevant? | PTL Comments | From Defcore Discussion | Scorer Comments | |
---|---|---|---|---|---|---|---|---|---|---|---|
2 | identity-v3-tokens-create | platform/compute/object | required | POST | /v3/auth/tokens | 1 | yes | The returned token value is in the X-Auth-Token header | stay? | tempest.api.identity.v3.test_tokens{test_create_token} | |
3 | identity-v3-api-discovery | platform/compute | advisory | 3 | yes | make required | tempest.api.identity.v3.test_api_discovery{test_api_version_resources, test_api_media_types, test_api_version_statuses} | ||||
4 | |||||||||||
5 | identity-v2-list-versions | GET | / | 1 | yes | soon to be deprecated | |||||
6 | identity-v2-show-version | GET | /v2.0 | 1 | yes | soon to be deprecated | |||||
7 | identity-v2-token-generation | POST | /v2.0/tokens | 1 | yes | soon to be deprecated | |||||
8 | identity-v2-tenants | GET | /v2.0/tenants | 1 | yes | is this an admin call? if so, not a candidate | |||||
9 | identity-v2-list-extensions | GET | /v2.0/extensions | soon to be deprecated | |||||||
10 | identity-v2-show-extension | GET | /v2.0/extensions/{alias} | soon to be deprecated | |||||||
11 | |||||||||||
12 | identity-v3-create-ec2-credentials | POST | /v3/credentials | 1 | yes | Should we make ec2 compatibility required? unclear | |||||
13 | identity-v3-list-ec2-credentials | GET | /v3/credentials | 1 | yes | Should we make ec2 compatibility required? unclear | |||||
14 | identity-v3-show-ec2-credentials | GET | /v3/credentials/{credential_id} | 1 | yes | Should we make ec2 compatibility required? unclear | |||||
15 | identity-v3-delete-ec2-credentials | DELETE | /v3/credentials/{credential_id} | 1 | yes | Should we make ec2 compatibility required? unclear | |||||
16 | identity-v3-update-ec2-credentials | PATCH | /v3/credentials/{credential_id} | Should we make ec2 compatibility required? unclear | |||||||
17 | identity-v3-catalog | (make sure it works on all supported releases) | returned with the token | ||||||||
18 | identity-v3-password-update | POST | /v3/users/{user_id}/password | 1 | yes | Untestable without changing user's password, security risk. Also password policies are very particular to different companies, making a test that would pass on all is near impossible. | tempest.api.identity.v3.test_users{test_update_own_password} | ||||
19 | |||||||||||
20 | identity-v3-list-projects | platform/compute | GET | /v3/users/{user_id}/projects | 0 | yes | no test available for this feature | ||||
21 | identity-v3-list-groups | platform/compute | GET | /v3/users/{user_id}/groups | 0 | yes | no test available for this feature | ||||
22 | identity-v3-get-project | platform/compute | GET | /v3/projects/{project_id} | 0 | yes | admin required | ||||
23 | identity-v3-list-roles | platform/compute | GET | /v3/roles | 0 | no | admin required | ||||
24 | identity-v3-get-role | platform/compute | GET | /v3/roles/{role_id} | no | admin required | |||||
25 | identity-v3-list-domains | platform/compute | GET | /v3/domains | no | admin required | |||||
26 | identity-v3-get-domain | platform/compute | GET | /v3/domains/{domain_id} | no | admin required | |||||
27 | |||||||||||
28 | identity-v3-validate-token | platform/compute | GET | /v3/auth/tokens | yes | Token to be validated is passed in the X-Subject-Token header | This sounds backwards to me, need to check with steve, shouldn't it be POST for validating and GET for getting a token?? | ||||
29 | identity-v3-revoke-token | platform/compute | DELETE | /v3/auth/tokens | 1 | yes | Token to be revoked is passed in the X-Subject-Token header | keystone.keystone.tests.unit.test_revoke{test_revoke_by_user} | |||
30 | identity-v3-get-catalog | platform/compute/object | GET | /v3/auth/catalog | 0 | yes | couldn't find a test specific for this, there are some tests related in keystone.tests.unit.test_v3_auth.py | ||||
31 | identity-v3-get-auth-projects | platform/compute | GET | /v3/auth/projects | 0 | yes | equivalent as far as I can tell to identity-v3-list-projects. couldn't find a test specific for this, there are some tests related in keystone.tests.unit.test_v3_auth.py |