IMHO changing the default value now is not a good option here. If we change the default value in tempest, nova, glance (and so on, if exists) it means that deployment would break during upgrade unless users explicitly set these options to the legacy value or update keystone endpoints to use the new type. This sounds like a quite breaking change which makes upgrade of real deployments difficult. May I know if there is any clear downside of using 'volumev3' ? To be honest based on the fact that "volumev3" has been used as default and mentioned in docs for very long time, I find it little valuable while it has big use impact. On 10/5/24 01:50, Ghanshyam Mann wrote:
---- On Fri, 04 Oct 2024 09:48:25 -0700 Ghanshyam Mann wrote ---
---- On Fri, 04 Oct 2024 09:12:13 -0700 Artem Goncharov wrote ---
Hey Stephen
On Friday, 4 October 2024 15:15:08 GMT+2 Stephen Finucane wrote:
o/
I've proposed a series of patches to "clean up" the service catalog that DevStack creates in a deployment. Currently, DevStack creates two endpoints for Cinder: one called 'cinderv3' of type 'volumev3' and another called 'cinder' of type 'block-storage'. For example:
{ "services": [ { "name": "cinderv3", "description": "Cinder Volume Service V3", "id": "65460706a9864e71926f13042f526aeb", "type": "volumev3", "enabled": true, "links": { "self": "http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb" } }, { "name": "cinder", "description": "Cinder Volume Service", "id": "cd406a0e296d47dca1e481e992851bb2", "type": "block-storage", "enabled": true, "links": { "self": "http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2" } }, // ... ], "links": { "next": null, "self": "http://10.0.108.50/identity/v3/services", "previous": null } }
They both ultimately point to the same API, the Cinder v3 API, meaning one of these endpoints is redundant. My assumption was 'block-storage' was the correct one, since that's the official service type [1], and that 'cinder' was the appropriate name since it mirrors what we use for other services (nova, neutron, keystone, glance, ...). However, tkajinam raised the point [2] that the Install Guide currently recommends use of the 'volumev3' type and that projects like Nova and Glance have an '[cinder] catalog_info' that defaults to 'volumev3'. If so, is 'block-storage' really the official service type, or is it 'volumev3'. If it is, should we be changing the Install Guide and the various config option defaults?
Previously we had volumev2 and volumev3. Those are both versioned aliases to the block-storage as the official service type name (that is what structure of the service-types-authority claims). Now there is no volumev2 and thus the confusion grows. I suggest looking at the rendered json at [2] which states: ``` "cinder": { "aliases": [ "volumev3", "volumev2", "volume", "block-store" ], "api_reference": "https://docs.openstack.org/api-ref/block-storage/", "project": "cinder", "service_type": "block-storage" }, ```
Catalog consumption process is in detail described at [3]. It is insanely complex and confusing but that is what all tools that look at the service catalog do.
Overall: - official and unique service_type of the cinder is block-storage - volumev3 is an alias pointing to explicit v3 api of block-storage - there was an "idea" that once a service exposing multiple API versions (and those are exposed independently with version-suffixed service types) there is an unversioned one pointing to the "latest" version (therefore typically you also find `volume` service pointing to the v3 - technically install docs should stop suggesting registering volumev3 including project_id suffix. This is in detail addressed by the service catalog consumption procedure and in addition blosk-storage v3 api has a series of APIs without project_id. Continuing appending project_id in the service catalog is heavily harmful. - install docs may switch to registering `block-storage` or `volume` instead of volumev3 and even stop pointing it to the v3 api explicitly since version discovery is there to figure out all the aspects.
With the API version changing and just to keep backward compatibility of devstack among tooling, we kept modifying the catalog name in this way and ended up with more confusion.
I agree to make the cinder catalogue also consistent with others and name them only 'blosk-storage'.
Tempest still uses 'volumev3' as the default cinder service catalog, but that is something we should change as first:
- https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8...
Just saw that you already proposed that. thanks ++
https://review.opendev.org/c/openstack/tempest/+/930296
-gmann
-gmann
[1] https://specs.openstack.org/openstack/service-types-authority/
[2] https://service-types.openstack.org/service-types.json [3]