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