Skip to content

v3 resources missing links.self (HATEOAS), blocks tempest parity #1082

Description

@gtema

No v3 resource response body includes a links.self field (or roles_links/similar per-item HATEOAS links), matching python keystone's convention. Only collection pagination gets a links array today, via crate::api::common::build_pagination_links (crates/keystone/src/api/common.rs) -- individual resource representations (trust, project, user, role, ...) never get one.

This silently blocks tempest parity: tempest.api.identity.admin.v3.test_trusts.* (and likely other admin.v3 suites) index resource['links']['self'] directly in Python test code -- not via JSON-schema validation -- so a missing key is a hard KeyError, not a lenient skip.

Found while fixing OS-TRUST trust create/list/get/delete (python-rust API compat, tracked under #938): trust creation, role-by-name resolution, and JSON field serialization are all now correct and unit-tested, but every tempest.api.identity.admin.v3.test_trusts.* test still fails on KeyError: 'links' once past trust creation.

Reusing scim/location.rs's resource_location()/config.default.public_endpoint pattern would be the natural building block, but this needs a decision on scope before implementation:

  • Which resources get a links.self (all v3 resources, to match python keystone, or only the ones tempest currently exercises)?
  • Whether it belongs on a shared trait/helper applied per-handler, or is added ad hoc per resource.

Referenced from #938.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions