Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

When nova-api receives a API request (e.g. server list), it validates the token passed to from the client it against keystone. But in order to do that, it has to first authenticate against keystone using it's own credentials 401 Unauthorised most likely means, that nova-api was unable to authenticate with keystone (and this is "unauthorised" to access the URL used for validating tokens).

In other words, this is most likely caused by credentials in /etc/nova/nova.conf of the node hosting the nova-api being out of sync with the actual credentials assigned to the nova user.

[root@openstack1 ~]# cat /etc/nova/nova.conf  | grep ^admin_
admin_user=nova
admin_password=zT8SsObhAHdqqgZPc
admin_tenant_name=service

Check those against what you think is set for the nova user in openstack.

You can easily confirm this theory. Issuing the following command (with XXXs replaced with whatever was returned with the command above) should work on a healthy OpenStack deployment.

curl -i -X POST http://10.0.25.2:5000/v2.0/tokens -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-keystoneclient" -d '{"auth": {"tenantName": "XXXX", "passwordCredentials": {"username": "XXX", "password": "XXXX"}}}'

When nova-api receives a API request (e.g. server list), it validates the token passed to from the client it against keystone. But in order to do that, it has to first authenticate against keystone using it's own credentials 401 Unauthorised most likely means, that nova-api was unable to authenticate with keystone (and this is "unauthorised" to access the URL used for validating tokens).

In other words, this is most likely caused by credentials in /etc/nova/nova.conf of the node hosting the nova-api being out of sync with the actual credentials assigned to the nova user.

[root@openstack1 ~]# cat /etc/nova/nova.conf  | grep ^admin_
admin_user=nova
admin_password=zT8SsObhAHdqqgZPc
admin_tenant_name=service

Check those against what you think is set for the nova user in openstack.

You can easily confirm this theory. Issuing the following command (with XXXs replaced with whatever was returned with the command above) should work on a healthy OpenStack deployment.deployment. If it doesn't, this means nova's credentials are off somewhere (either in nova.conf or in keystone db).

curl -i -X POST http://10.0.25.2:5000/v2.0/tokens -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-keystoneclient" -d '{"auth": {"tenantName": "XXXX", "passwordCredentials": {"username": "XXX", "password": "XXXX"}}}'