openstack team mailing list archive

[Kevin Jackson <kevin@xxxxxxxxxxxxxxxxxxx>]

Thanks Adam for clarifying the position of the ENVVARS: SERVICE_ENDPOINT
and SERVICE_TOKEN.
There are a couple of issues I have with this though:

1) It's not clear that these are strictly over-riding envvars.
2) The bug I've raised has been marked invalid - but I'd like to argue that
this is a user-interface bug with the keystone client.  If a user has an
option to specify options on the command line in context with what he/she
is doing - they shouldn't be overriden by an environment variable because
that user is specifically trying to achieve the goal of authentication in
those options.  These should over-ride the environment variables because
the user specifically put these on the command line to ensure there are no
ambiguities.

I'd appreciate the thoughts on this and why this route was chosen, though.

Cheers,

Kev

On 9 March 2012 10:06, Kevin Jackson <kevin@xxxxxxxxxxxxxxxxxxx> wrote:

> Ah, sorry - didn't make myself clear.
>
> I tried both token and user/pass approaches separately to see if one
> approach worked and not another.  They were giving the same response.
>
> Bug is https://bugs.launchpad.net/keystone/+bug/949904
>
> Regards,
>
> Kev
>
>
> On 8 March 2012 19:09, Adam Gandelman <adamg@xxxxxxxxxxxxx> wrote:
>
>>  Hey Kevin-
>>
>> Some stuff in-line
>>
>>
>> On 03/08/2012 06:08 AM, Kevin Jackson wrote:
>>
>> Dear all,
>> I've just installed Ubuntu 12.04 B1 with OpenStack from the Ubuntu repos.
>>
>>  I've set up keystone as per:
>> https://github.com/uksysadmin/OpenStackInstaller/blob/essex/keystone-services.sh(which I based on the
>> keystone.openstack.org docs)
>>
>>
>> Thanks for the handy script!
>>
>>
>>
>>  I have raised a bug under Keystone (though more than likely this could
>> be a Ubuntu specific bug from this version), but reading on the mailing
>> list, hints that others have gotten further perhaps.
>>
>>
>> Bug #?
>>
>>
>>
>>  On setting up my environment vars (SERVICE_ENDPOINT, SERVICE_TOKEN) and
>> trying --username and --password based auth to keystone I can view my
>> endpoints, list users, roles, etc.
>>
>>
>> I think you're confusing the two sets of credentials.  Currently,
>> SERVICE_ENDPOINT + SERVICE_TOKEN are used to run admin commands against
>> keystone (user-list, endpoint-create, etc)  With these set, all commands
>> are run in admin context against the admin URL (ks_host:35357/v2.0/)
>> User-level commands (catalog, token-get, discover, etc) require regular
>> user credentials passed and auth_url set to the :5000/v2.0/ URL.  I believe
>> the SERVICE_ENDPOINT + SERVICE_TOKEN environment variables override
>> user-level credentials in keystone client, so if you're setting both you'll
>> be hitting the admin URL which does not support the user-level stuff.
>>
>> I used your script to bootstrap a fresh keystone and things worked as
>> expected as long as the two user environments are kept isolated.
>>
>> HTH,
>> Adam
>>
>>
>>
>>
>>  On trying to do the following I get problems:
>>
>>  $ keystone discover
>>  root@openstack2:/etc/keystone# keystone discover
>> No handlers could be found for logger "keystoneclient.client"
>> No Keystone-compatible endpoint found
>>
>>  root@openstack2:/etc/keystone# keystone token-get
>> 'Client' object has no attribute 'service_catalog'
>>
>>  root@openstack2:/etc/keystone# keystone catalog
>> 'Client' object has no attribute 'service_catalog'
>>
>>  Any pointers in what I've done wrong will be super.
>>
>>  Cheers,
>>
>>  Kev
>> --
>> Kevin Jackson
>> @itarchitectkev
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>
>
> --
> Kevin Jackson
> @itarchitectkev
>



-- 
Kevin Jackson
@itarchitectkev