Prefer versioned service type aliases #3350
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Here's how I'm testing this using a local DevStack:
I would appreciate anyone that has run into this issue doing the same, perhaps with modifications to use
package main
import (
"context"
"fmt"
"os"
"github.com/gophercloud/gophercloud/v2"
"github.com/gophercloud/gophercloud/v2/openstack"
"github.com/gophercloud/gophercloud/v2/openstack/blockstorage/v3/volumes"
)
func main() {
ao, err := openstack.AuthOptionsFromEnv()
if err != nil {
panic(err)
}
client, err := openstack.AuthenticatedClient(context.TODO(), ao)
if err != nil {
panic(err)
}
blockStorage, err := openstack.NewBlockStorageV3(client, gophercloud.EndpointOpts{Region: os.Getenv("OS_REGION_NAME")})
if err != nil {
panic(err)
}
pager, err := volumes.List(blockStorage, nil).AllPages(context.TODO())
if err != nil {
fmt.Println(err)
return
}
volumes, err := volumes.ExtractVolumes(pager)
if err != nil {
fmt.Println(err)
return
}
fmt.Println("volumes:")
for i, volume := range volumes {
fmt.Printf(" volume %d: id=%s\n", i, volume.ID)
}
}
module gophercloud-version-workaround
go 1.23.8
require github.com/gophercloud/gophercloud/v2 v2.7.0
replace github.com/gophercloud/gophercloud/v2 => /home/stephenfin/code/gophercloud/gophercloud |
We do not need to check the validity of the provided opts more than once so don't. We can also simplify our handling of multiple endpoints. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
As noted inline, this allows us to prefer what the user (or we) requested until such a time as this is no longer necessary. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Currently, we iterate through endpoints first, comparing them to the request service type and its aliases. This means that endpoints which use an alias can end up being selected ahead of endpoints that use the requested type. Invert this logic so that we prefer endpoints that match our requested type ahead of those that match an alias of the requested type. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
If we requested volumev2 then we obviously don't want to match on volumev3. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This is a partial revert of e394733. Prefer e.g. volumev3 or sharev2 to block-storage or shared-file-systems as a temporary measure while we work on versioned API discovery. Couple with prior changes, this means if we e.g. have two catalog entries with services types of 'volumev2' and 'volumev3' (in that order!) and we request a service with 'volumev3', we will return the latter catalog entry ahead of the former. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
18206ab to
f710413
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in #3349, Gophercloud currently lacks support for version discovery. This means it is reliant on the use of versioned service type aliases (e.g.
volumev3) in deployments where there are multiple API versions (and therefore multiple service catalog entries) present for a given service, something that #3209 (and the #3327 backport) failed to account for.The long-term fix is to add the missing version discovery feature, but that's going to involve a bit of work and rigorous testing. Until we get that done, let's rework things so that we start preferring versioned service types aliases but still fallback to the official service type and the other unversioned service types aliases if necessary. This is achieved via a few discrete steps:
NewFooVXhelpers, thus triggering all of the above.Fixes #3347