🚨 OpenStack Error Guide: 'Could not determine a suitable URL for the plugin' endpoint failure

Exact Error Message

$ openstack volume list
Could not determine a suitable URL for the plugin

$ openstack image list
EndpointNotFound: public endpoint for image service in RegionOne region not found

In a service log the keystoneauth traceback looks like:

2026-06-27 13:05:41.227 9 ERROR keystoneauth1.exceptions.catalog
keystoneauth1.exceptions.catalog.EndpointNotFound: Could not find requested endpoint in Service Catalog.
2026-06-27 13:05:41.227 9 ERROR keystoneauth1   File ".../keystoneauth1/session.py", line 940, in get_endpoint
2026-06-27 13:05:41.227 9 ERROR keystoneauth1     raise exceptions.EndpointNotFound("Could not determine a suitable URL for the plugin")

What the Error Means

After Keystone authenticates you, the client must turn a service type (volumev3, image, network) plus an interface (public, internal, admin) and a region into a concrete URL by looking them up in the service catalog the token carries. “Could not determine a suitable URL for the plugin” means that lookup failed: the catalog has no entry matching the requested service type, interface, and region combination.

This is almost never an authentication problem — the token is valid. It is a catalog problem. Either the endpoint was never registered, it was registered for a different interface or region than the client is asking for, the service entry is disabled, or the client’s environment is requesting an interface (often internal or admin) that does not exist in the deployment.

Common Causes

• Missing endpoint for the service — the service was registered but one or more of its public/internal/admin endpoints were never created.
• Wrong --os-interface / OS_INTERFACE — the client asks for internal but only a public endpoint exists (common after copying admin RC files to a different host).
• Region mismatch — OS_REGION_NAME does not match the region the endpoint was registered under (RegionOne vs regionOne vs a custom name).
• Service or endpoint disabled — openstack endpoint set --disable or a disabled service hides it from the catalog.
• Catalog scoped wrong — an unscoped or system-scoped token returns a catalog without the project-scoped service entries.
• Typo in service type — a stale plugin or alias requesting volume instead of volumev3.

How to Reproduce the Error

The simplest reproduction is an interface mismatch:

1. Source an RC file and set export OS_INTERFACE=internal.
2. Confirm via openstack endpoint list that the target service only has a public endpoint.
3. Run openstack volume list.

The client requests the internal interface, finds no matching catalog entry, and raises “Could not determine a suitable URL for the plugin.” Deleting a service’s endpoint entirely reproduces the missing-endpoint variant for any client that calls it.

Diagnostic Commands

These are read-only and run as an admin (or any user whose token returns the full catalog).

# What the client thinks it is asking for
env | grep -E 'OS_INTERFACE|OS_REGION_NAME|OS_AUTH_URL|OS_IDENTITY_API_VERSION'

# What the catalog actually contains
openstack catalog list
openstack endpoint list --service volumev3
openstack endpoint list --interface internal
openstack service list

+----------------------------------+-----------+--------------+
| ID                               | Region    | Service Name |
+----------------------------------+-----------+--------------+
| 2a1c... (publicURL only)         | RegionOne | cinderv3     |
+----------------------------------+-----------+--------------+

Inspect logs if a service-to-service call is failing rather than your CLI:

# Kolla-Ansible
docker logs cinder_api 2>&1 | grep -i "suitable URL\|EndpointNotFound" | tail
# Traditional packages
journalctl -u openstack-cinder-api | grep -i "suitable URL\|EndpointNotFound" | tail

Step-by-Step Resolution

1. Identify the exact triple the client wants: service type, interface, region. The error names the plugin; your environment names the interface and region. Most failures are an interface or region the catalog does not contain.

2. List the endpoints that actually exist for that service:

   openstack endpoint list --service volumev3

   Compare the Interface and Region columns against what the client requested.

3. Fix the client first if the catalog is correct. If the endpoints exist only as public but OS_INTERFACE=internal, change the client:

   export OS_INTERFACE=public
   openstack --os-interface public volume list

4. Register the missing endpoint if the catalog is incomplete. Create the absent interface for the service in the right region:

   openstack endpoint create --region RegionOne volumev3 internal https://cinder.internal.example.com/v3/%\(project_id\)s

   Repeat for public/admin as your deployment requires.

5. Re-enable a disabled service or endpoint if openstack service list or endpoint list shows it disabled:

   openstack endpoint set --enable <endpoint-id>
   openstack service set --enable <service-id>

6. Correct a region-name mismatch. Ensure OS_REGION_NAME exactly matches the registered region (case-sensitive). Re-run the failing command to confirm the URL now resolves.

Prevention and Best Practices

• Register all three interfaces (public, internal, admin) for every service at deploy time, even if some point to the same host, so clients with different RC files all resolve.
• Keep one canonical region name and reference it consistently in every RC file and configuration template.
• Validate the catalog after any Keystone bootstrap or service addition with openstack catalog list before declaring the deployment healthy.
• Distribute RC files that set OS_INTERFACE to the value appropriate for where the client runs (control plane → internal, operator laptop → public).
• Alert on EndpointNotFound in service logs — when one service cannot find another’s endpoint, dependent operations fail silently until the catalog is fixed.

Related Errors

• EndpointNotFound: public endpoint for <service> in <region> region not found — the explicit, fully-qualified form of the same catalog miss.
• The resource could not be found. (HTTP 404) from a service URL that exists in the catalog but points at a dead host.
• Could not find versioned identity endpoints — a related discovery failure, usually a wrong OS_AUTH_URL. See our /categories/openstack/ Keystone guides.
• Authorization Failed: ... (HTTP 401) — authentication, not catalog; a different failure mode entirely.

Frequently Asked Questions

Is this an authentication failure? No. The token authenticated successfully. The failure happens afterward, when the client tries to map a service type and interface to a URL in the catalog.

Why does it work for admin but not a regular user? The catalog can vary by scope. An admin token may carry endpoints a project-scoped or system-scoped token does not. Reproduce with the same scope the failing client uses.

What is the difference between public, internal, and admin interfaces? They are separate endpoint URLs registered per service: public for external clients, internal for control-plane-to-service traffic over a management network, and admin for privileged operations. Clients choose one via OS_INTERFACE.

Could a region typo really cause this? Yes. Region names are case-sensitive strings. regionOne and RegionOne are different regions to the catalog, and a mismatch yields no suitable URL.

Does Kolla-Ansible register endpoints automatically? Kolla-Ansible registers endpoints during deployment, but a partial deploy, a manually added service, or a service enabled after the fact can leave the catalog incomplete — verify with openstack catalog list.