GET info from the nova service = 404

Here are the Keystone DB tables for endpoint and service:

select * from endpoint;
+----------------------------------+-----------+----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id | region | service_id | extra |
+----------------------------------+-----------+----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 418d09ce2ce8430bad19a07b37fa79f7 | RegionOne | 605a619a483b4ec187604fee5f52bd96 | {"adminurl": "http://10.38.8.7:8773/services/Admin", "internalurl": "http://10.38.8.7:8773/services/Cloud", "publicurl": "http://10.38.8.7:8773/services/Cloud"} |
| 7fb598b9fa8f4fd7a20b7568b118989c | RegionOne | 034cd436b6a945f89ecbb250c989eabd | {"adminurl": "http://10.38.8.7:8776/v1", "internalurl": "http://10.38.8.7:8776/v1", "publicurl": "http://10.38.8.7:8776/v1"} |
| a4e678c811d84cedb4bb93695382962b | RegionOne | 43de4c0cef38444b89306ed9b545be2e | {"adminurl": "http://10.38.8.7:9292/v1", "internalurl": "http://10.38.8.7:9292/v1", "publicurl": "http://10.38.8.7:9292/v1"} |
| b22891b075ef46b48ebc195b30f9e09b | RegionOne | b3c7d1fd7aa3449d9d9633c27ef42480 | {"adminurl": "http://10.38.8.7:5000/v2.0", "internalurl": "http://10.38.8.7:35357/v2.0", "publicurl": "http://10.38.8.7:35357/v2.0"} |
| d23a0a5534004daeb9962ceb520d6a29 | RegionOne | 5bcdb47361bf433a8f2a04d0f6a2f809 | {"adminurl": "http://10.38.8.7:8774/v2", "internalurl": "http://10.38.8.7:8774/v2", "publicurl": "http://10.38.8.7:8774/v2"} |
+----------------------------------+-----------+----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------+
5 rows in set (0.00 sec)

select * from service;
+----------------------------------+----------+-------------------------------------------------+
| id | type | extra |
+----------------------------------+----------+-------------------------------------------------+
| 034cd436b6a945f89ecbb250c989eabd | volume | {"description": "Volume", "name": "volume"} |
| 43de4c0cef38444b89306ed9b545be2e | image | {"description": "Glance", "name": "glance"} |
| 5bcdb47361bf433a8f2a04d0f6a2f809 | compute | {"description": "nova Compute", "name": "nova"} |
| 605a619a483b4ec187604fee5f52bd96 | ec2 | {"description": "EC2", "name": "ec2"} |
| b3c7d1fd7aa3449d9d9633c27ef42480 | identity | {"description": "Keystone", "name": "keystone"} |
+----------------------------------+----------+-------------------------------------------------+
5 rows in set (0.00 sec)

I am adding another comment, I installed DevStack on a different server to test. No surprise, it's working. However, I found something interesting when running: nova --debug nova

nova --debug list
connect: (192.168.19.129, 5000)
send: 'POST /v2.0/tokens HTTP/1.1\r\nHost: 192.168.19.129:5000\r\nContent-Length: 101\r\ncontent-type: application/json\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: python-novaclient\r\n\r\n{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "password": "mypass"}}}'
reply: 'HTTP/1.1 200 OK\r\n'
header: Content-Type: application/json
header: Vary: X-Auth-Token
header: Content-Length: 2265
header: Date: Tue, 10 Apr 2012 06:01:09 GMT
connect: (192.168.19.129, 8774)
send: u'GET /v2/1a4c8892dc664f9bb48d901cfaa5cf2f/servers/detail HTTP/1.1\r\nHost: 192.168.19.129:8774\r\nx-auth-project-id: admin\r\nx-auth-token: 4a48baa1eb8f4a609c8e1cafef12a8d5\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: python-novaclient\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
header: X-Compute-Request-Id: req-0e3cd3d5-d6ce-4474-b846-55cd596a62ca
header: Content-Type: application/json
header: Content-Length: 15
header: Date: Tue, 10 Apr 2012 06:01:09 GMT
+----+------+--------+----------+
| ID | Name | Status | Networks |
+----+------+--------+----------+
+----+------+--------+----------+

I noticed the different output form an install to another:

Doesn't work: send: u'GET /v2/servers/detail
Work: send: u'GET /v2/1a4c8892dc664f9bb48d901cfaa5cf2f/servers/detail

The working one has the token in the URL. Is that something about the endpoints?

Hello,

Anyone have an idea on how to fix this problem?
Thanks

Are you using SQL catalog or tempaltecatalog?
you can check the config in keystone.conf:
[catalog]
# dynamic, sql-based backend (supports API/CLI-based management commands)
# driver = keystone.catalog.backends.sql.Catalog

# static, file-based backend (does *NOT* support any management commands)
driver = keystone.catalog.backends.templated.TemplatedCatalog
template_file = ./etc/default_catalog.templates

Since you are giving out SQL data, I assume it is SQL Catalog. I think the endpoints should have some variables just like template one:
# config for TemplatedCatalog, using camelCase because I don't want to do
# translations for keystone compat
catalog.RegionOne.identity.publicURL = http://controlnode:$(public_port)s/v2.0
catalog.RegionOne.identity.adminURL = http://controlnode:$(admin_port)s/v2.0
catalog.RegionOne.identity.internalURL = http://controlnode:$(public_port)s/v2.0
catalog.RegionOne.identity.name = Identity Service

# fake compute service for now to help novaclient tests work
catalog.RegionOne.compute.publicURL = http://controlnode:$(compute_port)s/v1.1/$(tenant_id)s
catalog.RegionOne.compute.adminURL = http://controlnode:$(compute_port)s/v1.1/$(tenant_id)s
catalog.RegionOne.compute.internalURL = http://controlnode:$(compute_port)s/v1.1/$(tenant_id)s
catalog.RegionOne.compute.name = Compute Service

catalog.RegionOne.volume.publicURL = http://controlnode:8776/v1/$(tenant_id)s
catalog.RegionOne.volume.adminURL = http://controlnode:8776/v1/$(tenant_id)s
catalog.RegionOne.volume.internalURL = http://controlnode:8776/v1/$(tenant_id)s
catalog.RegionOne.volume.name = Volume Service

FYI, I'm seeing this very same behavior with 2012.1-0ubuntu2 on Ubuntu Precise Beta2 (+ updates) after following Essex "Install and Deploy" manual and working around obvious documentation errors (for which I've submitted bugs).

I'm using the SQL catalog in Keystone... Keystone itself appears to be working fine, it delivers up credentials per "Verifying the Identity Service Installation" (via curl method, etc.), strace of the nova command itself shows keystone service delivering credential after request, and "nova credentials" work as expected.

However, nova-api only delivers the "ERROR: n/a (HTTP 404)" error for requests like "nova list", "nova image-list", etc.

- Jim Collins