Hmm, well it looks like you already have debug enabled, which is indicating that the username + password combination is bad (if debug was disabled, you'd get a much more opaque error message). The tenant name you specified would not have been checked yet. If 'admin' appears in your keystone user-list, then the password is definitely wrong.
-Dolph On Sat, Apr 13, 2013 at 3:56 PM, Daniel Ellison <dan...@syrinx.net> wrote: > On 2013-04-13, at 1:24 PM, Dolph Mathews <dolph.math...@gmail.com> wrote: > > It looks like you're doing everything correctly, except OS_PASSWORD is > *NOT* the same thing as the static admin_token in keystone.conf. > > You're right, actually. I DID use the admin_token for OS_PASSWORD. I'll > definitely be fixing that. But as long as the password is set and > referenced properly it shouldn't matter what it is, I would hope. > > > Passwords are user-specific attributes created using the --pass argument > on user-create for example. You may have set it to be the same as > keystone.conf's admin_token, but I necessarily wouldn't recommend that. If > you don't know what your password was, you probably need to delete your > admin user and recreate it with a known password, and then grant it your > admin role again. > > The keystone_data.sh script did this correctly, using the ADMIN_PASSWORD I > set at the top of the script. That password happened to be the admin_token, > but again, as long as it's set properly it shouldn't make a difference. As > I mentioned, I think I'll fix that anyway, just to take it out of the > equation. > > Thanks for the response! > Daniel
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp