* require specification of user id or name
* until the time where keystone support of default tenant is well defined require specification of tenant id or name
* require keystone endpoint
QUESTIONS:
* for auth strategies - do we support multiple at this point? If not should we remain mute on this until we know more?
* if the proposed requirements are ok, then we can argue OS_USER_ID vs OS_AUTH_USER_ID vs OS_AUTH_USER... Do we need the word AUTH?
ASSUMPTIONS:
* both glance and nova would updated their docs to reflect the new env variables - but would continue supporting during ESSEX their deprecated variables. (pulling from them if new-style variables aren't set)
NOTE:
Keystone IDs vs NAMEs
While both ids and names are meant to be unique, IDs are immutable whereas the name can change
proposal for id/name/password flow:
* require specification of user id or name
* until the time where keystone support of default tenant is well defined require specification of tenant id or name
* require keystone endpoint
QUESTIONS:
* for auth strategies - do we support multiple at this point? If not should we remain mute on this until we know more?
* if the proposed requirements are ok, then we can argue OS_USER_ID vs OS_AUTH_USER_ID vs OS_AUTH_USER... Do we need the word AUTH?
ASSUMPTIONS:
* both glance and nova would updated their docs to reflect the new env variables - but would continue supporting during ESSEX their deprecated variables. (pulling from them if new-style variables aren't set)
NOTE:
Keystone IDs vs NAMEs
While both ids and names are meant to be unique, IDs are immutable whereas the name can change