пт, 29 нояб. 2024 г. в 19:41, Stephen Finucane <stephenfin@redhat.com>:
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.
Are we not mixing up service names with service types? Or do we actually expect ppl to refer to https://service-types.openstack.org as a source of truth? As I learned about its presence not so long ago... For me, service type is pretty much permanent, smth on which clients can rely on and retrieve underlying service name and endpoint for it, but not what clients need to account as a variable. I would not care at all if we were talking about service names, but I'm quite surprised that types are treated the same way. Also looking at the keystoneauth right now - `service_type = 'volume'`, so probably early to say it's complying with naming convention. https://opendev.org/openstack/keystoneauth/blame/commit/bd152b19f7d5b3029fa5...
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.
Well, changing catalog during upgrade with installation tooling is the least of issues here. Thinking about that and some context you've provided - indeed nobody stops from leaving both service types in the catalog until upgrade is done and clean-up afterwards. Nothing complex from an installation tooling perspective, imo.
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.
Quite some software (any kind of billing, SaaS/PaaS on top of OpenStack, etc.) exists these days which utilizes OpenStack as a IaaS layer and is not written in Python. And I'd expect there's more software in the wild not using keystoneauth that actually does, even if they're python-based.
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.
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.
Cheers, Stephen