openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #08868
Keystone auth_token confusion in Swift vs Glance; Persistent tokens or not ?
Hello all,
I need some help with inconsistencies and -- in my mind -- confusing
instructions wrt "auth_token" Keytone middleware.
So far I have Keystone and Swift w/ Keystone auth working well together
(ussing Essex-4 milestone release of Keystone resp v1.4.6 of Swift).
What I am now trying is to get Glance on Swift with Keystone Auth but
I'm faced with conflicting info that I cannot make sense of
1) Naming inconsistencies -- "token_auth" , "tokenauth" (Keystone resp
Swift) vs "authtoken" (Glance)
The existing Keystone and Swift docs (e.g. this one:
http://keystone.openstack.org/configuringservices.html#configuring-swift-to-use-keystone
* ) *use as names "token_auth" (Keystone) resp "tokenauth" (Swift)
wheareas in Glance docs the same midldleware (i.e.
"keystone/middleware/auh_token.py") is referred to as "authtoken" (see
e.g. here http://glance.openstack.org/authentication.html )
While this may be only pedantic IMHO it would help if things would be
called the same way in different places. Or, if I'm confusing things,
someone point me out the differences to which is what and why.
2) "auth_token": Persistent tokens or user/pass ?
As per Jay Pipes comment here:
https://bugs.launchpad.net/glance/+bug/953989/comments/2 (from
2012-03-13) the concept of long-lived (i.e. persistent) tokens are no
longer supported by the Keystone "auth_token" middleware -- and that is
listed as why that bug was invalid.
Now, that gets me _really_ confused: My working Keystone (again, as per
E4) + Swift (as per v1.4.6) use persistent tokens just fine. E.g. my WSGI
pipleline for the swift proxy server looks like this:
[pipeline:main]
pipeline = catch_errors healthcheck cache tokenauth keystone proxy-server
......
with the corresponding:
...
[filter:keystone]
paste.filter_factory = keystone.middleware.swift_auth:filter_factory
operator_roles = admin, SwiftOperator
[filter:tokenauth]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
service_protocol = http
service_port = 5000
service_host = 127.0.0.1
auth_port = 5001
auth_host = 127.0.0.1
admin_token = 999888777666
delay_auth_decision = 0
...
Now, the question is: Since we are now to stop using long-lived tokens
hardcoded as "admin_token" in "keystone.conf", resp in the "auth_token"
middleware sections of swift resp, glance, how is a user/pass config
supposed to look like ? examples ?
Sorry if this question is not as clearly laid out is it should be, reason
is this is all very confusing to me .... (maybe time for me to get a rubber
ducky and explain it all ...)
Thanks in advance for the help,
Florian
Follow ups