-
Notifications
You must be signed in to change notification settings - Fork 560
Configure and respect service type aliases #3209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure and respect service type aliases #3209
Conversation
I'm not sure whether we want to expose the aliases via a new field in EDIT: Also, I'm surprised this has attracted the |
@stephenfin I think that |
If I do that, it'll be a breaking API change though, which means I can't fix this until V3? |
right. we can implement this in V3. |
Okay. So is what we have here good enough for now, in v2? What are your thoughts on my questions above? |
c0e9fff
to
84236e0
Compare
This allows us to request an endpoint by either its service type or one of its aliases. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This demonstrates an unhappy path that we may wish to deprecate in the future, but no mechanism exists for doing aside from logging, which we don't do anywhere else. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
We now have alias support and Gophercloud will automatically negotiate on our behalf. This means we set the service types to their official value rather than one of the aliases. Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
84236e0
to
e394733
Compare
@@ -22,6 +24,31 @@ const ( | |||
AvailabilityInternal Availability = "internal" | |||
) | |||
|
|||
// ServiceTypeAliases contains a mapping of service types to any aliases, as | |||
// defined by the OpenStack Service Types Authority. Only service types that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would have been nice to provide a link (for each service) of the code where we can find the alias. But I'm fine as is now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, many months later, if someone is curious:
All the Cinder jobs have a failure, we need to check whether it's related here. |
Fixed here 5a3e9f6 Reported here https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/QQ7L44VE4MOWOQVOFCZQPTIVI35A6SCK/ |
Despite the official service type being block-storage, cinder only accepts volume as the service type in the OpenStack-API-Version header :( Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
6428ace
to
5a3e9f6
Compare
Turns out this is because of my addition of the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our CI is awesome.
@stephenfin I'd like this to be backported. |
…scovery Configure and respect service type aliases
…scovery Configure and respect service type aliases
Merge pull request #3209 from shiftstack/proper-service-discovery
} | ||
|
||
// NewSharedFileSystemV2 creates a ServiceClient that may be used to access the v2 shared file system service. | ||
func NewSharedFileSystemV2(client *gophercloud.ProviderClient, eo gophercloud.EndpointOpts) (*gophercloud.ServiceClient, error) { | ||
return initClientOpts(client, eo, "sharev2") | ||
return initClientOpts(client, eo, "shared-file-system") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have the suspicion that this somehow reverted our usage to sharev1 from sharev2. Any hints how to properly debug this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would setting the Type on the endpoint opts also work?
diff --git a/internal/liquids/manila/liquid.go b/internal/liquids/manila/liquid.go
index 2a15d01a..b524ec9a 100644
--- a/internal/liquids/manila/liquid.go
+++ b/internal/liquids/manila/liquid.go
@@ -25,7 +25,6 @@
"math"
"regexp"
"strconv"
- "strings"
"time"
"github.com/gophercloud/gophercloud/v2"
@@ -74,12 +73,11 @@ func (l *Logic) Init(ctx context.Context, provider *gophercloud.ProviderClient,
}
// initialize connection to Manila
+ eo.Type = "sharev2"
l.ManilaV2, err = openstack.NewSharedFileSystemV2(provider, eo)
if err != nil {
return err
}
- // Workaround for gophercloud 2.7.0 which gets the first found OpenStack URL for Manila.
- l.ManilaV2.Endpoint = strings.Replace(l.ManilaV2.Endpoint, "v1", "v2", 1)
microversion, err := l.findMicroversion(ctx, l.ManilaV2)
if err != nil {
return err
I'm confused why this patch was accepted at all. You're just aliasing |
V3 is exactly V2 but with micro version support so requesting V3 without a micro version gets you V2 equivilant API. |
So then the problem is only with including the v1 APIs in the list ( |
The issue here is that we are missing service discovery, i.e. the equivalent of |
The interim fix is available here #3350 |
Fixes #3207
This means we can identify a service by either its type or any of its official aliases, which is the expectation when it comes to navigating the service catalog.