Ok, sorry, I missed this whole thread and about to start the discussion from the very beginning....
In that case, we should keep ' block-storage' always pointing to the latest and recommended version, and if we have an old one still supported, then change that to something else, for example, ' block-storage-legacy' or 'block-storage-v3'. This is how we did for nova v2 ('compute-legacy') vs v2.1 ('compute') API.
So a suggestion in the deployment guide to name cinder as `volumevN` is in there for at very least for 7 years [1]. Which means that *a lot* of deployments are already following this naming convention which we suggested. Now we say that with the next upgrade we're basically re-naming one of core service types from being `volumev3` to `block-storage`. I totally agree that this will result in confusion and chaos among end users in case it's not handled accordingly during upgrade. Also I totally see how such an upgrade would be impossible to accomplish without the downtime, as existing services will keep trying to refer to volumev3 type until being reconfigured and restarted. So at very least such change should have a grace period/upgrade path for users. But next to that, I totally agree that we would still need to have some "legacy"/"current" type. But then again - having "legacy" doesn't solve challenges for OpenStack upgrades. As once you start pointing service to it's new service type, all other dependent projects will start failing instantly, as they do not expect radical change in the API responses. For upgrade to pass nicely, you'd need to have legacy behaviour to act the same way until upgrade is finished. Only then can you change the behaviour of it, which always makes it easier/simler for the end users to create a new type for the new API. For me this was always the reason why having `volumev3` made some sense. [1] https://opendev.org/openstack/cinder/blame/branch/master/doc/source/install/... пт, 29 нояб. 2024 г. в 15:25, Stephen Finucane <stephenfin@redhat.com>:
On Fri, 2024-10-04 at 14:15 +0100, 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?
Cheers, Stephen
[1] https://specs.openstack.org/openstack/service-types-authority/
Following up on the above, I've noticed that Cinder only accepts 'volume' as the service type in 'OpenStack-API-Version' header. Is this correct? Surely it should accept 'block-storage' given that's the official service type? Before I go fix this, is there any reason why this is the case?
Stephen