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

...

[1] https://specs.openstack.org/openstack/service-types-authority/

[2] https://service-types.openstack.org/service-types.json [3]

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]

On 10/5/24 02:03, Artem Goncharov wrote:

On Fri, Oct 4, 2024, 18:56 Takashi Kajinami <kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> wrote:

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.

There should be no impact at all as long as keystoneauth lib is used which implements service/version discovery. If services hard coded service type of cinder without implementing discovery it is clearly a bug and must be fixed instead of sticking to keeping bugs forever what we do so often.

I'm not following this. Even if we use keystoneauth, we should know the service type to look up the correct endpoint from the list. Or are you saying that we can determine the endpoint for cinder without service_type field ? There are number of implementations which hard-code volumev3 or use the volumev3 as default. https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&excludeFiles=&repos= examples: https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/... https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/... https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volume... We may be need to make these at least configurable.

In addition to that a split between upgrade vs. new install should be implemented (install docs should explicitly recommend proper usage while existing installations may stick to their current configuration). Moreover nothing prevents adding multiple values to the catalog and drop older ones once all consumers are updated to follow the discovery procedure.

I agree we can add multiple service types and endpoints for the same service. However my main concern is that not all users may be aware of the required steps to avoid inconsistency caused by such change of default behavior. I can easily imagine that users upgrade their deployment and now their services require block-storage service type without noticing they should create that "new" service type.

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 <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 <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2>" >   >  > > } >   >  > >             }, >   >  > >             // ... >   >  > >         ], >   >  > >         "links": >   >  > >         { >   >  > >             "next": null, >   >  > >             "self": "http://10.0.108.50/identity/v3/services <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/ <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... <https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8cffe39/tempest/config.py#L981> > > Just saw that you already proposed that. thanks ++ > > https://review.opendev.org/c/openstack/tempest/+/930296 <https://review.opendev.org/c/openstack/tempest/+/930296> > > -gmann > >   > >   > -gmann >   >  > >   >  > > >   >  > > [1]

This procedure is followed in keystoneauth, openstacksdk, rust SDK/cli so no users should be affected unless they explicitly ignored official rules. ---- typed from mobile, auto-correct typos assumed ---- On Fri, Oct 4, 2024, 19:23 Artem Goncharov <artem.goncharov@gmail.com> wrote:

Official procedure is described at https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.h...

You know the service that you want to talk to and there is a list of service types that the service supports. You follow the procedure to find the one set by your cloud.

---- typed from mobile, auto-correct typos assumed ----

On Fri, Oct 4, 2024, 19:19 Takashi Kajinami <kajinamit@oss.nttdata.com> wrote:

...

On 10/5/24 02:03, Artem Goncharov wrote:

...

On Fri, Oct 4, 2024, 18:56 Takashi Kajinami <kajinamit@oss.nttdata.com

<mailto:kajinamit@oss.nttdata.com>> wrote:

...

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.

There should be no impact at all as long as keystoneauth lib is used

which implements service/version discovery.

...

If services hard coded service type of cinder without implementing discovery it is clearly a bug and must be fixed instead of sticking to keeping bugs forever what we do so often.

I'm not following this. Even if we use keystoneauth, we should know the service type to look up the correct endpoint from the list. Or are you saying that we can determine the endpoint for cinder without service_type field ?

There are number of implementations which hard-code volumev3 or use the volumev3 as default.

https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&excludeFiles=&repos=

examples:

https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/...

https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/...

https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volume...

We may be need to make these at least configurable.

...

In addition to that a split between upgrade vs. new install should be implemented (install docs should explicitly recommend proper usage while existing installations may stick to their current configuration). Moreover nothing prevents adding multiple values to the catalog and drop older ones once all consumers are updated to follow the discovery procedure.

I agree we can add multiple service types and endpoints for the same service. However my main concern is that not all users may be aware of the required steps to avoid inconsistency caused by such change of default behavior.

I can easily imagine that users upgrade their deployment and now their services require block-storage service type without noticing they should create that "new" service type.

...

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": > > > > "

...

" > > > > } > > > > }, > > > > { > > > > "name": "cinder", > > > > "description": "Cinder Volume Service", > > > > "id": "cd406a0e296d47dca1e481e992851bb2", > > > > "type": "block-storage", > > > > "enabled": true, > > > > "links": > > > > { > > > > "self": > > > > " http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 " > > > > } > > > > }, > > > > // ... > > > > ], > > > > "links": > > > > { > > > > "next": null, > > > > "self": " http://10.0.108.50/identity/v3/services < 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

http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb <http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb 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/ < 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... < https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8...

...

> > Just saw that you already proposed that. thanks ++ > > https://review.opendev.org/c/openstack/tempest/+/930296 <

https://review.opendev.org/c/openstack/tempest/+/930296>

...

> > -gmann > > > > > -gmann > > > > > > > > > > > [1]

OK. Thanks for the explanation. I then probably misunderstood the impact of the change. It sounds like as long as we use appropriate SDK in a proper manner, we can look up the endpoint with official service type by legacy service type and vise versa, because of internal translation which I was not aware of. If that is true, I agree the change has no impact unless something too hacky is made in services. On 10/5/24 02:26, Artem Goncharov wrote:

This procedure is followed in keystoneauth, openstacksdk, rust SDK/cli so no users should be affected unless they explicitly ignored official rules.

---- typed from mobile, auto-correct typos assumed ----

On Fri, Oct 4, 2024, 19:23 Artem Goncharov <artem.goncharov@gmail.com <mailto:artem.goncharov@gmail.com>> wrote:

Official procedure is described at https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.h... <https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.html>

You know the service that you want to talk to and there is a list of service types that the service supports. You follow the procedure to find the one set by your cloud.

---- typed from mobile, auto-correct typos assumed ----

On Fri, Oct 4, 2024, 19:19 Takashi Kajinami <kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> wrote:

On 10/5/24 02:03, Artem Goncharov wrote: > > > > On Fri, Oct 4, 2024, 18:56 Takashi Kajinami <kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com> <mailto:kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>>> wrote: > >     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. > > > > There should be no impact at all as long as keystoneauth lib is used which implements service/version discovery. > If services hard coded service type of cinder without implementing discovery it is clearly a bug and must be fixed instead of sticking to keeping bugs forever what we do so often.

I'm not following this. Even if we use keystoneauth, we should know the service type to look up the correct endpoint from the list. Or are you saying that we can determine the endpoint for cinder without service_type field ?

There are number of implementations which hard-code volumev3 or use the volumev3 as default.

https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&excludeFiles=&repos= <https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&excludeFiles=&repos=>

examples: https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/... <https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/api/cinder.py#L218> https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/... <https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/cinder.py#L40> https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volume... <https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volume/discovery.py#L22>

We may be need to make these at least configurable.

> In addition to that a split between upgrade vs. new install should be implemented (install docs should explicitly recommend proper usage while existing installations may stick to their current configuration). Moreover nothing prevents adding multiple values to the catalog and drop older ones once all consumers are updated to follow the discovery procedure.

I agree we can add multiple service types and endpoints for the same service. However my main concern is that not all users may be aware of the required steps to avoid inconsistency caused by such change of default behavior.

I can easily imagine that users upgrade their deployment and now their services require block-storage service type without noticing they should create that "new" service type.

> > > >     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 <http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb> <http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb <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 <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2> <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 <http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2>>" >      >   >  > > } >      >   >  > >             }, >      >   >  > >             // ... >      >   >  > >         ], >      >   >  > >         "links": >      >   >  > >         { >      >   >  > >             "next": null, >      >   >  > >             "self": "http://10.0.108.50/identity/v3/services <http://10.0.108.50/identity/v3/services> <http://10.0.108.50/identity/v3/services <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/ <https://docs.openstack.org/api-ref/block-storage/> <https://docs.openstack.org/api-ref/block-storage/ <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... <https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8cffe39/tempest/config.py#L981> <https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8... <https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8cffe39/tempest/config.py#L981>> >      > >      > Just saw that you already proposed that. thanks ++ >      > >      > https://review.opendev.org/c/openstack/tempest/+/930296 <https://review.opendev.org/c/openstack/tempest/+/930296> <https://review.opendev.org/c/openstack/tempest/+/930296 <https://review.opendev.org/c/openstack/tempest/+/930296>> >      > >      > -gmann >      > >      >   > >      >   > -gmann >      >   >  > >      >   >  > > >      >   >  > > [1] >

---- On Mon, 07 Oct 2024 07:35:09 -0700 Rajat Dhasmana wrote ---

Hi, Summarizing the history of endpoints to make it easier to understand the timeline.Looking at the history of changes in devstack, initially we used the convention volume, volumev2 and volumev3 for endpoints pointing to different cinder API versions v1, v2 and v3[1] respectively.Overtime we removed v1 and v2[2] as their support came to end of life.The endpoint for block-storage was added around 1 year after the addition of volumev3 endpoint and both have existed in the catalog for ~7 years. From an official project name perspective, block-storage seems to be the right choice and is consistent with other OpenStack services in the endpoint catalog.From a legacy point of view, volumev have been the convention followed and adopted by Cinder and other OpenStack projects. My preference would be to use block-storage endpoint if we can identify/fix all the issues associated with the change.One question which I'm unsure about is, if we plan a Cinder v4 version, would it again create this conflict of a new volumev4 endpoint?

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

[1] https://opendev.org/openstack/devstack/commit/06c7a4404edf25b9a4d913e77d12a2f61a608053[2] https://opendev.org/openstack/devstack/commit/35cec0d7c0857d76d3ea0b52b97f2a166c04c13e[3] https://opendev.org/openstack/devstack/commit/cda2cb557f7176c431d151b32bc44e... ThanksRajat Dhasmana On Fri, Oct 4, 2024 at 11:19 PM Takashi Kajinami kajinamit@oss.nttdata.com> wrote: OK. Thanks for the explanation. I then probably misunderstood the impact of the change. It sounds like as long as we use appropriate SDK in a proper manner, we can look up the endpoint with official service type by legacy service type and vise versa, because of internal translation which I was not aware of.

If that is true, I agree the change has no impact unless something too hacky is made in services.

On 10/5/24 02:26, Artem Goncharov wrote:

...

This procedure is followed in keystoneauth, openstacksdk, rust SDK/cli so no users should be affected unless they explicitly ignored official rules.

---- typed from mobile, auto-correct typos assumed ----

On Fri, Oct 4, 2024, 19:23 Artem Goncharov artem.goncharov@gmail.com artem.goncharov@gmail.com>> wrote:

     Official procedure is described at https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.h... https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.html>

     You know the service that you want to talk to and there is a list of service types that the service supports. You follow the procedure to find the one set by your cloud.

     ----      typed from mobile, auto-correct typos assumed      ----

     On Fri, Oct 4, 2024, 19:19 Takashi Kajinami kajinamit@oss.nttdata.com kajinamit@oss.nttdata.com>> wrote:

         On 10/5/24 02:03, Artem Goncharov wrote:           >           >           >           > On Fri, Oct 4, 2024, 18:56 Takashi Kajinami kajinamit@oss.nttdata.com kajinamit@oss.nttdata.com> kajinamit@oss.nttdata.com kajinamit@oss.nttdata.com>>> wrote:           >           >     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.           >           >           >           > There should be no impact at all as long as keystoneauth lib is used which implements service/version discovery.           > If services hard coded service type of cinder without implementing discovery it is clearly a bug and must be fixed instead of sticking to keeping bugs forever what we do so often.

         I'm not following this. Even if we use keystoneauth, we should know the service type          to look up the correct endpoint from the list. Or are you saying that we can determine          the endpoint for cinder without service_type field ?

         There are number of implementations which hard-code volumev3 or use the volumev3 as default.

         https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&excludeFiles=&repos= https://codesearch.opendev.org/?q=volumev3&i=nope&literal=nope&files=&excludeFiles=&repos=>

         examples:          https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/... https://opendev.org/openstack/horizon/src/branch/master/openstack_dashboard/api/cinder.py#L218>          https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/... https://opendev.org/openstack/heat/src/branch/master/heat/engine/clients/os/cinder.py#L40>          https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volume... https://opendev.org/openstack/ceilometer/src/branch/master/ceilometer/volume/discovery.py#L22>

         We may be need to make these at least configurable.

          > In addition to that a split between upgrade vs. new install should be implemented (install docs should explicitly recommend proper usage while existing installations may stick to their current configuration). Moreover nothing prevents adding multiple values to the catalog and drop older ones once all consumers are updated to follow the discovery procedure.

         I agree we can add multiple service types and endpoints for the same service. However my main          concern is that not all users may be aware of the required steps to avoid inconsistency caused by          such change of default behavior.

         I can easily imagine that users upgrade their deployment and now their services require block-storage          service type without noticing they should create that "new" service type.

          >           >           >           >     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 http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb> http://10.0.108.50/identity/v3/services/65460706a9864e71926f13042f526aeb 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 http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2> http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2 http://10.0.108.50/identity/v3/services/cd406a0e296d47dca1e481e992851bb2>>"           >      >   >  > > }           >      >   >  > >             },           >      >   >  > >             // ...           >      >   >  > >         ],           >      >   >  > >         "links":           >      >   >  > >         {           >      >   >  > >             "next": null,           >      >   >  > >             "self": "http://10.0.108.50/identity/v3/services http://10.0.108.50/identity/v3/services> http://10.0.108.50/identity/v3/services 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/ https://docs.openstack.org/api-ref/block-storage/> https://docs.openstack.org/api-ref/block-storage/ 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... https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8cffe39/tempest/config.py#L981> https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8... https://github.com/openstack/tempest/blob/da14e2972243e4890e3ef6889bf5a85ee8cffe39/tempest/config.py#L981>>           >      >           >      > Just saw that you already proposed that. thanks ++           >      >           >      > https://review.opendev.org/c/openstack/tempest/+/930296 https://review.opendev.org/c/openstack/tempest/+/930296> https://review.opendev.org/c/openstack/tempest/+/930296 https://review.opendev.org/c/openstack/tempest/+/930296>>           >      >           >      > -gmann           >      >           >      >   >           >      >   > -gmann           >      >   >  >           >      >   >  > >           >      >   >  > > [1]           >

On Fri, 2024-11-29 at 17:06 +0100, Dmitriy Rabotyagov wrote:

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.

As has been mentioned elsewhere in the thread, clients are responsible for negotiating services types and should respect the data published in the service type authority data. keystoneauth has been doing this for year. Gophercloud is able to do this now. In an ideal world installation tooling would migrate to use the correct service type when initially generating the service catalog, but the alias is as valid as it's ever been and no one's proposing removing that.

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.

gtema already said this but I'll repeat: this won't happen if they're using keystoneauth, pretty much any of the legacy clients, or openstacksdk. Just so you're aware, the change to DevStack merged a few months ago. To the best of my knowledge, it broke two OpenStack projects (due them having their own non- compliant client implementations) and Gophercloud (which wasn't respecting aliases). These three issues are resolved now.

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.

As above: clients already handle this.

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.

The example you snipped from gmann was hypothetical, but yes, in the unlikely event that there's ever a block-storage v4 API then we will need to think about this. However, we will also need to think about this for *every* other service other than Cinder, Manila, Mistral, which are the only versions with a version suffix. Most of those have been around for years without major version bumps. Suffice to say, I don't think this is an issue. Cheers, Stephen

[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

On 11/29/24 21:28, Dmitriy Rabotyagov wrote:

...

The example you snipped from gmann was hypothetical, but yes, in the unlikely event that there's ever a block-storage v4 API then we will need to think about this. However, we will also need to think about this for *every* other service other than Cinder, Manila, Mistral, which are the only versions with a version suffix. Most of those have been around for years without major version bumps. Suffice to say, I don't think this is an issue. I'm not sure I've read the gmann example when I was writing it, but even if I was. The fact that it's unlikely we have a need with current temp of development, does not mean we should design processes to be cumbersomely complex if the need appears. And kind of having a suffix feels more future-proof overall than not having it, despite I see where logic comes from - that type should not be versioned, it's underlying implementation can be instead. But the truth is, that when a major change in api version happens, these changes are usually not backwards compatible and severe. In fact, the service can behave very differently then it used to be, so giving it the same type can also be misleading.

The suffix was and is absolutely useless. The only thing it serves is to "bind" api version to the service type name. But that is also addressed using official service catalog consumption process. When a service implements version discovery there is absolutely no need in having versioned types. In addition to that you are mixing service type name and it's official aliases: there is no difference between volume and block-storage (as well as volumev3 and block-storagev3) service type name. The version suffix physically binds it to the version api name and when service does implement version discovery. When versioned endpoint does NOT match the real api version it is going to be refused according to the catalog consumption process. Summary, - block-storage is the official service type in according to the service-types authority - volume is one of the official aliases for the block-storage type - version prefix can be used for main name and for aliases but should not be used at all when service implements version discovery (what Cinder does). Adding new api version does not require introduction of the new versioned service type - this is a great misunderstanding that it does. The only exception is when service does not implement version discovery. Artem