My last post showed how to load the user data using curl. This is only interesting if you love curl. Its pretty easy to do the same thing from the command line. Now, we at Keystone central hate responsibility. We have no desire to do more than we have to. That includes wrint the Command Line Client.
There is an effort afoot to move to a unified command line. Here is a sneak peek:
To get this to work took a little finagling: When a user gets a token, it contains the URL for the Keystone admin port, and the CLI uses this to perform the user create action. There is work going to to do better discoverability (figure out which version of the API is supported), but until then, you can do the following hack (not recommended for production)
Edit the database
mysql --user keystone --password=keystone keystone
Make the admin URL V3 specific:
update endpoint set url='http://127.0.0.1:35357/v3' where url like 'http://127.0.0.1:35357/%';
Restart Keystone.
And you can use the command:
export OS_AUTH_URL=http://127.0.0.1:5000/v3 export OS_USERNAME=admin export OS_PASSWORD=freeipa4all export OS_TENANT_NAME=admin openstack --os-identity-api-version=3 user create testname2 --password=testme --project=demo --domain=default
So my previous example would be reduced to:
while read USERNAME ; do openstack --os-identity-api-version=3 user create $USERNAME --password=changeme --project=demo ; done < usernames.txt
Well, I think you could have used python-keystoneclient to update your endpoints (keystone endpoint-*) ; )
And I agree that there’s work to do with the clients libraries and CLI. In that way, I submitted a patch to allow users of the python-keystoneclient library to be able to choose between v2 or v3 identity endpoints, by specifying a “service_type”: https://review.openstack.org/#/c/64834/
Cheers
That was one of the thoughts, but it will explode the Service catalog. Catalog is already too big, and there are problems with token size going over 8 K