Comment 4 for bug 853933

My 2 cents: We will always need for the Client class to take the auth token as an optional argument; this is the way we can allow nova to access glance with the user's credentials. If we need this here, then it seems to me that it will also be useful from the command line; instead of getting an auth token each time we try to use it, we have the capability of getting the auth token once and using it over and over, which could be handy in some sort of automated processing. As an example, consider an admin that wants to write a shell script that scans through glance images, examining the metadata of each for an expiration timestamp, and deletes those images that have expired. Without --auth-token, Keystone will be hit potentially 2N times, whereas with it, we can potentially hit Keystone once and reuse those credentials over and over. (And yes, if I were writing this, I'd write it using the Python API; but I don't think we want to require admins to learn Python just to build fairly simple management tools.)

Long-term, I'd like to see the client authentication plugin that hits Keystone provide two different means of specifying credentials: the current user/tenant/password scheme, and an auth token scheme. My full plugin architecture idea would provide command line arguments for these; the environment variables are kind of a stop-gap that Rick used for now.