Skip to content

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

Merged
merged 5 commits into from
Nov 29, 2024

Conversation

stephenfin
Copy link
Contributor

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.

@github-actions github-actions bot added edit:openstack This PR updates common OpenStack code edit:gophercloud This PR updates common Gophercloud code edit:blockstorage This PR updates blockstorage code semver:major Breaking change labels Oct 10, 2024
@stephenfin
Copy link
Contributor Author

stephenfin commented Oct 10, 2024

I'm not sure whether we want to expose the aliases via a new field in EndpointOpts like I've done here, or if it would be simpler to stick with a single Type field and do the mapping of service type to aliases inside V2EndpointURL / V3EndpointURL in openstack/endpoint_location.go. What we've done here is more obvious, but I'm not allowing users to override the aliases maybe exposing it is wholly unnecessary? 🤷 Open to thoughts here.

EDIT: Also, I'm surprised this has attracted the semver:major label. I only changed internal methods (various versions of initClientOpts) which I had assumed to be fair game. 😕

@kayrus
Copy link
Contributor

kayrus commented Oct 10, 2024

@stephenfin I think that NewClient functions also need to support aliases, so users can override them for custom service like block-storage-beta

@coveralls
Copy link

coveralls commented Oct 10, 2024

Coverage Status

coverage: 78.681% (-0.05%) from 78.726%
when pulling 5a3e9f6 on shiftstack:proper-service-discovery
into 24c9641 on gophercloud:master.

@stephenfin
Copy link
Contributor Author

@stephenfin I think that NewClient functions also need to support aliases, so users can override them for custom service like block-storage-beta

If I do that, it'll be a breaking API change though, which means I can't fix this until V3?

@kayrus
Copy link
Contributor

kayrus commented Oct 11, 2024

right. we can implement this in V3.

@stephenfin
Copy link
Contributor Author

Okay. So is what we have here good enough for now, in v2? What are your thoughts on my questions above?

@stephenfin stephenfin force-pushed the proper-service-discovery branch from c0e9fff to 84236e0 Compare October 11, 2024 11:18
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>
@stephenfin stephenfin force-pushed the proper-service-discovery branch from 84236e0 to e394733 Compare November 29, 2024 11:26
@@ -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
Copy link
Contributor

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.

Copy link
Contributor

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:

https://service-types.openstack.org/

EmilienM
EmilienM previously approved these changes Nov 29, 2024
@EmilienM
Copy link
Contributor

All the Cinder jobs have a failure, we need to check whether it's related here.

@stephenfin
Copy link
Contributor Author

stephenfin commented Nov 29, 2024

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>
@stephenfin stephenfin force-pushed the proper-service-discovery branch from 6428ace to 5a3e9f6 Compare November 29, 2024 14:37
@stephenfin
Copy link
Contributor Author

stephenfin commented Nov 29, 2024

EDIT: Also, I'm surprised this has attracted the semver:major label. I only changed internal methods (various versions of initClientOpts) which I had assumed to be fair game. 😕

Turns out this is because of my addition of the Aliases field to EndpointOpts. It's a slice which is not comparable, thus EndpointOpts is no longer comparable. I think this is an okay exception to the backport policy but I'd like others to weigh in before I propose said backport.

Copy link
Contributor

@EmilienM EmilienM left a 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.

@EmilienM EmilienM merged commit fdb527e into gophercloud:master Nov 29, 2024
18 checks passed
@EmilienM EmilienM deleted the proper-service-discovery branch November 29, 2024 15:26
@kayrus
Copy link
Contributor

kayrus commented Mar 6, 2025

Turns out this is because of my addition of the Aliases field to EndpointOpts. It's a slice which is not comparable, thus EndpointOpts is no longer comparable. I think this is an okay exception to the backport policy but I'd like others to weigh in before I propose said backport.

@stephenfin I'd like this to be backported.
@EmilienM @mandre @pierreprinetti objections?

@EmilienM EmilienM added the backport-v2 This PR will be backported to v2 label Mar 11, 2025
@kayrus kayrus removed the semver:major Breaking change label Mar 11, 2025
@kayrus kayrus added the semver:minor Backwards-compatible change label Mar 11, 2025
kayrus pushed a commit to kayrus/gophercloud that referenced this pull request Mar 11, 2025
…scovery

Configure and respect service type aliases
@kayrus kayrus added semver:major Breaking change and removed semver:minor Backwards-compatible change labels Mar 11, 2025
kayrus pushed a commit to kayrus/gophercloud that referenced this pull request Mar 12, 2025
…scovery

Configure and respect service type aliases
mandre added a commit that referenced this pull request Mar 12, 2025
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")
Copy link
Contributor

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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

@majewsky
Copy link
Contributor

I'm confused why this patch was accepted at all. You're just aliasing volume, and volumev2 and volumev3 to each other, even though those are completely different APIs. How is this supposed to work on a theoretical level? If I'm asking for NewBlockStorageV3, giving back the v2 API is a categorically wrong answer.

@mnaser
Copy link
Contributor

mnaser commented Apr 16, 2025

V3 is exactly V2 but with micro version support so requesting V3 without a micro version gets you V2 equivilant API.

@majewsky
Copy link
Contributor

majewsky commented Apr 16, 2025

So then the problem is only with including the v1 APIs in the list (share and volume)?

@stephenfin
Copy link
Contributor Author

The issue here is that we are missing service discovery, i.e. the equivalent of keystoneauth.discover. I am working on a fix plus a interim partial revert to tide us through until it's ready. A full revert is not an option as what gophercloud was doing previously was not compliant with deployments using the correct service type rather than an alias. The DevStack change merely exposed this incorrect behaviour.

@stephenfin
Copy link
Contributor Author

The issue here is that we are missing service discovery, i.e. the equivalent of keystoneauth.discover. I am working on a fix plus a interim partial revert to tide us through until it's ready. A full revert is not an option as what gophercloud was doing previously was not compliant with deployments using the correct service type rather than an alias. The DevStack change merely exposed this incorrect behaviour.

The interim fix is available here #3350

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport-v2 This PR will be backported to v2 edit:blockstorage This PR updates blockstorage code edit:gophercloud This PR updates common Gophercloud code edit:openstack This PR updates common OpenStack code semver:major Breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Service type aliases are ignored
8 participants