Can't create user

SERVICE_TOKEN needs to be set in the environment, or admin_context is not set in keystone and the operation fails. Checkout devstack's files/keystone_data.sh for an example.

Hope that helps..

So I need different credentials for creating users than for creating
tenants? Really? Is that intentional?

Best regards, Soren.
Sent from my phone. Please pardon my brevity.
On Mar 21, 2012 2:45 PM, "David Lapsley" <email address hidden> wrote:

> SERVICE_TOKEN needs to be set in the environment, or admin_context is
> not set in keystone and the operation fails. Checkout devstack's
> files/keystone_data.sh for an example.
>
> Hope that helps..
>
> --
> You received this bug notification because you are a member of Keystone
> Bugs, which is subscribed to Keystone.
> https://bugs.launchpad.net/bugs/960977
>
> Title:
> Can't create user
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/keystone/+bug/960977/+subscriptions
>

It looks like there's something funky going on here, but I'm not quite sure what.

If you received "Invalid tenant (HTTP 401)" for a user-create, I would think you should have gotten one for a tenant-create as well. tenant-list can of course be done with non-admin credentials.

Worst case, it looks like you're allowed to create tenants without being admin (eek!)... however, I'm unable to reproduce that.

Can you post your env / did you alter it after running stack.sh? MIght offer some clues.

The transcript is from immediately after devstack has finished. I've made no customisations.

the user-create should not be used as you do.
To create a user by keystone, the command should be:
keystone user-create --name=somethingelse --pass="xxx" --<email address hidden>

and then bind tenant, role and user together by:
keystone user-role-add --user userid --role roleid --tenant_id idforsomethingtenant

Why did your command get error like that? Because you are specifying the tenant of admin to your newly created tenantid, which admin account is not in.

You can add --debug to see what is sending behind scene.

+++++++++++++++++++++++++++++++++++++++++++++++++
jenkins@Soren-1:~/devstack$ keystone tenant-create --name=something
+-------------+----------------------------------+
| Property | Value |
+-------------+----------------------------------+
| description | None |
| enabled | True |
| id | 1fbcafe2a91049dab2321180ea6cf567 |
| name | something |
+-------------+----------------------------------+
jenkins@Soren-1:~/devstack$ keystone user-create --name=somethingelse --tenant_id=1fbcafe2a91049dab2321180ea6cf567
No handlers could be found for logger "keystoneclient.client"
Invalid tenant (HTTP 401)
jenkins@Soren-1:~/devstack$ keystone user-create --name=somethingelse --tenant_id 1fbcafe2a91049dab2321180ea6cf567
No handlers could be found for logger "keystoneclient.client"
Invalid tenant (HTTP 401)
jenkins@Soren-1:~/devstack$ keystone tenant-list
+----------------------------------+--------------------+---------+
| id | name | enabled |
+----------------------------------+--------------------+---------+
| 1fbcafe2a91049dab2321180ea6cf567 | something | True |
| 894f670456884611b82a88a9231a0c9d | invisible_to_admin | True |
| e0d1e304feda4250b235c2fa6061d010 | demo | True |
| e2daf9dea45f482a8877fa9fe6c2e7e5 | admin | True |
| f6c5aeb7ab884912a9fabd59e14265a9 | service | True |
+----------------------------------+--------------------+---------+
jenkins@Soren-1:~/devstack$

Was able to reproduce using openrc from devstack, but I'm not clear on whether this issue lands on the keystone or devstack side of the fence yet.

Running `. openrc admin` should have actually been `. openrc admin admin`. The difference is that the first command leaves OS_TENANT_NAME set to 'demo' while the second explicitly sets it to `admin`. This is obviously just user error / doc bug / not very intuitive and lands on devstack.

Second, it looks like OS_TENANT_NAME is not effective (and still produces the "Invalid tenant (HTTP 401)" error. Setting `export OS_TENANT_NAME=` and instead using `export OS_TENANT_ID=<admin tenant ID>` appears to workaround the issue. Need to further investigate this issue in keystone/keystoneclient.

It appears that continued legacy support for --tenant_id (instead of --os_tenant_id) is overriding environment variables (OS_TENANT_ID and OS_TENANT_NAME), which conflicts when attempting to specify a user default tenant-id (also provided via --tenant_id).

Legacy support for --tenant_id in place of --os_tenant_id needs to be immediately removed because it conflicts with `user-create --tenant_id=...`.

Keystoneclient and Novaclient are using these differently

Keystone:
  OS_TENANT_NAME ... string of the tenant name - like "admin" or "demo"
  OS_TENANT_ID ... the UUID of the tenant

Nova
  OS_TENANT_NAME ... equiv to NOVA_PROJECT_ID - it's looking for the UUID, not the string name

SO:

I believe the OpenRC in horizon should emit both, and the python nova client should recognize OS_TENANT_ID instead of OS_TENANT_NAME for the relevant value.

Fix proposed to branch: master
Review: https://review.openstack.org/5974

Joe: I don't think this is correct. it is using OS_TENANT_NAME as the name of the tenant, but falling back to NOVA_PROJECT_ID because in older versions nova id and name were equivalent. You used to be able to set NOVA_PROJECT_ID in your env for old versions of nova-client, so that fallback is only there for compatibility reasons.

hhmm - that's not matching what I was seeing when I changed quotas (admittedly with the nova-manage command) and it didn't accept the name, only the UUID. I translated that over into nova-client too.

correct, internally nova uses the tenant_id as the project_id but the string you pass as OS_TENANT_NAME is what the novaclient uses to talk to KEYSTONE. It then grabs the token and a url to talk to nova. It doesn't pass in tenant directly. The project_id setting in nova comes from the tenant_id in the token matched against the url.

Reviewed: https://review.openstack.org/5974
Committed: http://github.com/openstack/python-keystoneclient/commit/e957119771154566b52cac93833465fc95ff03d8
Submitter: Jenkins
Branch: master

commit e957119771154566b52cac93833465fc95ff03d8
Author: Dolph Mathews <email address hidden>
Date: Thu Mar 29 14:54:24 2012 -0700

    Drop support for OS --tenant_id (bug 960977)

    Change-Id: I36849c53e1c63609fc9df7fcd1c245bb3d3a6872

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/6148

Reviewed: https://review.openstack.org/6148
Committed: http://github.com/openstack/python-keystoneclient/commit/316b0477d5ec7c1b7994524fff0e4d9afd402ca4
Submitter: Jenkins
Branch: milestone-proposed

commit 316b0477d5ec7c1b7994524fff0e4d9afd402ca4
Author: Dolph Mathews <email address hidden>
Date: Thu Mar 29 14:54:24 2012 -0700

    Drop support for OS --tenant_id (bug 960977)

    Change-Id: I36849c53e1c63609fc9df7fcd1c245bb3d3a6872