[cinder] Project ID in cinder endpoints and system scopes

Brian Rosmaita rosmaita.fossdev at gmail.com
Mon Nov 30 15:03:09 UTC 2020

 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:
where the <path> parts are defined in the Block Storage API reference:

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.)


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 at gandi.net

More information about the openstack-discuss mailing list