🚨 OpenStack Error Guide: 'EndpointNotFound: public endpoint for ... not found' — Fix the Service Catalog

Overview

EndpointNotFound is raised by keystoneauth when a client authenticates successfully but then cannot find a usable endpoint for the service it wants in Keystone’s service catalog. Authentication works; service discovery fails. The client asks the catalog “where is the image (or volume, or compute) API for this region and interface?” and the catalog has no matching entry.

The literal errors you will see:

keystoneauth1.exceptions.catalog.EndpointNotFound: public endpoint for image service in RegionOne region not found

Could not find requested endpoint in Service Catalog. (HTTP 404)
EndpointNotFound: internal endpoint for volumev3 service named cinderv3 not found

It appears the moment a CLI, Horizon, or a service-to-service call tries to resolve an endpoint — running openstack image list, opening the Images panel, or Nova calling Cinder. The key signal is that openstack token issue succeeds while openstack <service> list fails: the token is fine, the catalog entry is missing or wrong.

Symptoms

• openstack token issue works, but openstack image list / volume list / server list fails with EndpointNotFound.
• Horizon renders login and Identity panels but throws 404/“endpoint not found” on Images, Volumes, or Network.
• One service can’t call another (Nova → Cinder, Heat → any) after an endpoint/region change or redeploy.

openstack token issue -f value -c id >/dev/null && echo "auth OK"
openstack image list

auth OK
public endpoint for image service in RegionOne region not found

Common Root Causes

1. Endpoint missing from the catalog

The service (or its endpoint rows) was never registered, or was deleted during a redeploy.

openstack endpoint list --service glance -c "Service Name" -c Interface -c Region -c URL
openstack service list

# empty output, or glance service present with no endpoint rows

No row for the service means the client has nothing to resolve.

2. Wrong interface (public/internal/admin)

The client is asking for an interface the catalog doesn’t have. A clouds.yaml/OS_INTERFACE set to internal fails if only public was registered.

env | grep -E 'OS_INTERFACE|OS_ENDPOINT_TYPE'
openstack endpoint list --service cinderv3 -c Interface -c URL

OS_INTERFACE=internal
| public | https://<vip>:8776/v3/%(tenant_id)s |

Client wants internal; only public exists → EndpointNotFound.

3. Wrong or missing region

The token/CLI targets a region name that doesn’t match the registered endpoints (case-sensitive: RegionOne vs regionOne).

env | grep OS_REGION_NAME
openstack endpoint list -c Region -c "Service Name" | sort -u

OS_REGION_NAME=Region1
# but catalog only has RegionOne

4. Stale endpoint URL after a VIP / TLS / port change

The endpoints still point at an old VIP, http instead of https, or a changed port. The row exists, so it may not raise EndpointNotFound directly — but a redeploy that dropped and half-recreated endpoints often leaves gaps that do.

openstack endpoint list --service keystone -c Interface -c URL
grep -E '^auth_url|^www_authenticate_uri' /etc/keystone/keystone.conf

| public | http://192.0.2.10:5000/v3 |   # old VIP / wrong scheme

5. Service disabled in the catalog

The service or endpoint exists but is disabled, so it is excluded from the catalog handed to clients.

openstack service show glance -c enabled
openstack endpoint list --service glance -c Enabled -c Interface

| enabled | False |

6. Duplicate / conflicting endpoints

A partial re-register created two public rows for one service+region; keystoneauth can’t pick one deterministically.

openstack endpoint list --service neutron -c ID -c Interface -c Region

# two 'public' 'RegionOne' rows -> ambiguous

Diagnostic Workflow

Step 1: Prove auth works, isolate to the catalog

openstack token issue -c id -c expires
openstack catalog list          # what the client actually receives

If token issue succeeds but the failing service is absent from catalog list, it’s a catalog problem, not auth.

Step 2: Inspect the specific service’s endpoints

openstack service list
openstack endpoint list --service <service> -c Interface -c Region -c URL -c Enabled

Check that a row exists for the interface and region your client requests, and that it’s enabled.

Step 3: Confirm what the client is asking for

env | grep -E 'OS_INTERFACE|OS_REGION_NAME|OS_AUTH_URL'
# Kolla-Ansible: check the source-of-truth env
grep -E 'OS_INTERFACE|OS_REGION_NAME' /etc/kolla/admin-openrc.sh 2>/dev/null

Match interface and region against Step 2. Mismatch here is the most common cause.

Step 4: Check Keystone health and its own endpoint

docker logs keystone 2>&1 | grep -iE 'endpoint|catalog|404' | tail -10
openstack endpoint list --service keystone -c Interface -c URL

Step 5: Recreate a missing/wrong endpoint

openstack endpoint create --region RegionOne image public https://<vip>:9292
# repeat for internal / admin if your clouds use them
openstack endpoint list --service glance

For Kolla-Ansible, prefer re-running the deploy so endpoints match globals.yml:

kolla-ansible reconfigure -t keystone,glance

Example Root Cause Analysis

After moving the API behind a new HAProxy VIP, openstack server list works but openstack volume list fails:

EndpointNotFound: internal endpoint for volumev3 service named cinderv3 not found

token issue succeeds, so auth is fine. Inspecting the catalog:

openstack catalog list | grep -A2 -i cinder
openstack endpoint list --service cinderv3 -c Interface -c Region -c URL

| public | RegionOne | https://<vip>:8776/v3/%(project_id)s |

Only a public row exists — the internal and admin endpoints were dropped when the operator deleted and partially recreated Cinder endpoints during the VIP move. The workstation’s clouds.yaml uses OS_INTERFACE=internal, so keystoneauth finds no match.

Fix: recreate the missing internal (and admin) endpoints, then verify:

openstack endpoint create --region RegionOne volumev3 internal https://<vip>:8776/v3/%(project_id)s
openstack endpoint create --region RegionOne volumev3 admin    https://<vip>:8776/v3/%(project_id)s
openstack volume list      # now resolves and returns

Root cause: incomplete endpoint re-registration left a catalog gap for the requested interface. Longer term, let Kolla-Ansible own endpoints via reconfigure instead of hand-editing them.

Prevention Best Practices

• Register all three interfaces (public, internal, admin) consistently, and standardize OS_INTERFACE/OS_REGION_NAME across clouds.yaml and service configs.
• Let config management (Kolla-Ansible reconfigure) own endpoints so a VIP/TLS/port change updates every row atomically instead of by hand.
• After any endpoint or VIP change, smoke-test each service (openstack image/volume/server/network list) — catalog gaps only surface when a client resolves them.
• Keep region names exact and consistent; they are case-sensitive.
• Audit for duplicate endpoints (openstack endpoint list sorted by service+interface+region) after partial re-registrations.
• Monitor Keystone and alert on 404s from the catalog path.
• For a fast triage of a catalog error, paste the failing openstack command and endpoint list output into the free incident assistant, and see more OpenStack guides.

Quick Command Reference

# Prove it's the catalog, not auth
openstack token issue -c id
openstack catalog list

# Inspect the failing service's endpoints
openstack service list
openstack endpoint list --service <service> -c Interface -c Region -c URL -c Enabled

# What is the client asking for?
env | grep -E 'OS_INTERFACE|OS_REGION_NAME|OS_AUTH_URL'
grep -E 'OS_INTERFACE|OS_REGION_NAME' /etc/kolla/admin-openrc.sh 2>/dev/null

# Keystone health
docker logs keystone 2>&1 | grep -iE 'endpoint|catalog|404' | tail -10

# Recreate an endpoint (or let Kolla own it)
openstack endpoint create --region RegionOne image public https://<vip>:9292
kolla-ansible reconfigure -t keystone,glance

Conclusion

EndpointNotFound means Keystone authenticated the client but the service catalog has no usable endpoint for the requested service, interface, and region. The diagnostic signature is auth succeeding while service listing fails. Typical root causes:

1. The endpoint was never registered or was deleted in a redeploy.
2. The client requests an interface (internal/admin) that isn’t registered.
3. A region-name mismatch (case-sensitive).
4. Stale endpoint URLs after a VIP/TLS/port change, or a half-completed re-register.
5. The service or endpoint is disabled in the catalog.
6. Duplicate, ambiguous endpoint rows.

Compare what the client asks for (OS_INTERFACE/OS_REGION_NAME) against openstack endpoint list; the mismatch is almost always right there. Let Kolla-Ansible own endpoints so a single reconfigure keeps every interface and region consistent.