From the cinder side of the bug, there are two things going on here. (1) There's an ambiguity in the term "endpoint": it could be (a) the base URL where the service can be contacted, or (b) the JSON "url" element that shows up in the "endpoints" list of a service object in the "catalog" list in the service catalog. In sense (a), a project_id does not occur in the Block Storage API endpoint. The Block Storage REST API, however, does require a project_id in most of the URLs it recognizes. Thinking of an "endpoint" in sense (a), these look like: <endpoint><path> where the <path> parts are defined in the Block Storage API reference: https://docs.openstack.org/api-ref/block-storage/ When you look at the API reference, you'll see that for almost all calls, the Block Storage API requires a version indicator and project_id in the path. So if you leave these out, the service cannot resolve the URL and returns a 404. (2) Cinder doesn't support recognition of token scope in any released versions; we're working on it for Wallaby. (There's limited support in Victoria, but only for the default-types API.) cheers, brian On 11/30/20 4:35 AM, Nicolas Parquet wrote:
Hello there,
Wondering if anyone has ongoing work or information on the following bug: https://bugs.launchpad.net/keystone/+bug/1745905
We tried removing the project_id from cinder endpoints in order to test system scopes and see if more is needed than oslo policy configuration, but cannot get anything else than 404 responses.
The bug description suggests it is just a documentation issue, but I could not get a working setup. I also don't this mentioned in ptg documentation regarding system scopes support.
Any information or hint is welcome!
Regards,
-- Nicolas Parquet Gandi nicolas.parquet@gandi.net