Ask Your Question

Revision history [back]

If you are using policy.v3cloudsample.json , then set admin_domain_id = default in that policy file.

If you do that, then existing v2 users will continue to work and you can create new domain and add users to the domain. (.e) any user who is in default domain with "admin" role is considered cloudadmin. I don't want to confuse you, but horizon needs to support domain scoped tokens. V3 identity operations which relies on domain information ( domin/users/projects) will only work if you use domain scoped token if you use v3 policy file

If you are using policy.v3cloudsample.json , then set admin_domain_id = default in that policy file.

If you do that, then existing v2 users will continue to work and you can create new domain and add users to the domain. (.e) any user who is in default domain with "admin" role is considered cloudadmin. I don't want to confuse you, but horizon needs to support domain scoped tokens. V3 identity operations which relies on domain information ( domin/users/projects) will only work if you use domain scoped token if you use v3 policy file

Update 1:

1) Have you granted any roles for the users in the domain dom1 and projects?

2) Are you able to get token using the newly created user? Nova client doesn't support v3 command line. But you can use cinder client and it support v3. This is just to make sure you are able to get tokens. e.g cinder --debug list. Cinder client takes domain_id etc so you can get v3 tokens

If you are using policy.v3cloudsample.json , then set admin_domain_id = default in that policy file.

If you do that, then existing v2 users will continue to work and you can create new domain and add users to the domain. (.e) any user who is in default domain with "admin" role is considered cloudadmin. I don't want to confuse you, but horizon needs to support domain scoped tokens. V3 identity operations which relies on domain information ( domin/users/projects) will only work if you use domain scoped token if you use v3 policy file

Update 1:

1) Have you granted any roles for the users in the domain dom1 and projects?

2) Are you able to get token using the newly created user? Nova client doesn't support v3 command line. But you can use cinder client and it support v3. This is just to make sure you are able to get tokens. e.g cinder --debug list. Cinder client takes domain_id etc so you can get v3 tokens

Update 2: I'm going to suggest a different way to debug the problem, This will help us to understand what is going on.

1) Switch keystone to use  uuid token.
https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L1384
(i.e) under token section in keystone.conf
provider = keystone.token.providers.uuid.Provider

2) restart keystone 

3) Now get a token from keystone scoped to the project. Since it is uuid token, you can see the token response which has roles for the project.

4) Now try  your nova command. Since it is UUID token the token validation will come to keystone.  There you can see in keystone.log why the token was rejected.

5) If keystone authorizes the token and you are still getting rejected, then nova expects some role on that token which you are missing for that operation.

6) If the token is going from horizon to nova, then you can find out from the token id, the scope of the token. All the services need project scoped token. If horizon sends domain scoped token, then it is not going to work

If you are using policy.v3cloudsample.json , then set admin_domain_id = default in that policy file.

If you do that, then existing v2 users will continue to work and you can create new domain and add users to the domain. (.e) any user who is in default domain with "admin" role is considered cloudadmin. I don't want to confuse you, but horizon needs to support domain scoped tokens. V3 identity operations which relies on domain information ( domin/users/projects) will only work if you use domain scoped token if you use v3 policy file

Update 1:

1) Have you granted any roles for the users in the domain dom1 and projects?

2) Are you able to get token using the newly created user? Nova client doesn't support v3 command line. But you can use cinder client and it support v3. This is just to make sure you are able to get tokens. e.g cinder --debug list. Cinder client takes domain_id etc so you can get v3 tokens

Update 2: I'm going to suggest a different way to debug the problem, This will help us to understand what is going on.

1) Switch keystone to use  uuid token.
https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L1384
(i.e) under token section in keystone.conf
provider = keystone.token.providers.uuid.Provider

2) restart keystone 

3) Now get a token from keystone scoped to the project. Since it is uuid token, you can see the token response which has roles for the project.

4) Now try  your nova command. Since it is UUID token the token validation will come to keystone.  There you can see in keystone.log why the token was rejected.

5) If keystone authorizes the token and you are still getting rejected, then nova expects some role on that token which you are missing for that operation.

6) If the token is going from horizon to nova, then you can find out from the token id, the scope of the token. All the services need project scoped token. If horizon sends domain scoped token, then it is not going to work

Update 3:

  1. If you had enabled debug in kesytone, you would have seen the problem.
  2. Nova is sending V2 token validaton call which understands only "default" domain. Nova should send v3 token validation call. V3 is fully backward compatible with v2.0 3 Enable auth_version = v3 and restart nova
auth_version=v3.0
  1. In Juno, default version is v3 and not v2, so you would not have noticed this with latest code

If you are using policy.v3cloudsample.json , then set admin_domain_id = default in that policy file.

If you do that, then existing v2 users will continue to work and you can create new domain and add users to the domain. (.e) any user who is in default domain with "admin" role is considered cloudadmin. I don't want to confuse you, but horizon needs to support domain scoped tokens. V3 identity operations which relies on domain information ( domin/users/projects) will only work if you use domain scoped token if you use v3 policy file

Update 1:

1) Have you granted any roles for the users in the domain dom1 and projects?

2) Are you able to get token using the newly created user? Nova client doesn't support v3 command line. But you can use cinder client and it support v3. This is just to make sure you are able to get tokens. e.g cinder --debug list. Cinder client takes domain_id etc so you can get v3 tokens

Update 2: I'm going to suggest a different way to debug the problem, This will help us to understand what is going on.

1) Switch keystone to use  uuid token.
https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L1384
(i.e) under token section in keystone.conf
provider = keystone.token.providers.uuid.Provider

2) restart keystone 

3) Now get a token from keystone scoped to the project. Since it is uuid token, you can see the token response which has roles for the project.

4) Now try  your nova command. Since it is UUID token the token validation will come to keystone.  There you can see in keystone.log why the token was rejected.

5) If keystone authorizes the token and you are still getting rejected, then nova expects some role on that token which you are missing for that operation.

6) If the token is going from horizon to nova, then you can find out from the token id, the scope of the token. All the services need project scoped token. If horizon sends domain scoped token, then it is not going to work

Update 3:

  1. If you had enabled debug in kesytone, you would have seen the problem.
  2. Nova is sending V2 token validaton call which understands only "default" domain. Nova should send v3 token validation call. V3 is fully backward compatible with v2.0 3 Enable auth_version = v3 and restart nova
auth_version=v3.0
  1. In Juno, default version is v3 and not v2, so you would not have noticed this with latest code

Update 4: 1. Some services uses .conf and some other services using paste-ini to configure keystone settings. I believe for glance you need to add it in paste.init file https://github.com/openstack/glance/blob/master/etc/glance-api-paste.ini#L67

This question is becoming too big. If you think this is resolved, close this question and ask separate question.