Open Stack

*puts up hand*

You can blame me for this. When I implemented this I didn't (and still 
don't) fully understand how the loading stuff works in Keystoneauth and 
how it works with other things like OSC. I was more focused on getting 
the direct auth/session side working because the loading stuff isn't 
that useful in OSC really (see below why).

If anyone does know the loader side of keystoneauth better please chime 
in and save me from making too much of a fool of myself!

I think adding `.split(',')` is probably enough, but you'd want to also 
update the help text clarify that the option is a 'comma separated list'.


The biggest issue, and why this area never got much testing, is because 
it is effectively useless since you'd have to supply your MFA values 
EVERY command. Imagine how awful that would be for TOTP. The whole point 
of the MFA process in keystone with auth-receipt was a dynamic 
interactive login. Supplying the MFA upfront isn't that useful.

What the OSC really needs is a `login` command, that goes through a 
login process using the auth-receipts workflow from keystone (asks for 
password/totp) and sets some sort of state file. We can't set the 
environment variables of the parent shell process, so we'd have to go 
with a state/session file. But to avoid it clashing with other state 
files and terminal sessions we'd need some way to tag them by the parent 
process ID so you can login to more than one cloud/project/user/etc 
across multiple terminals.

In addition it would be really nice if the OSC had some way of reusing a 
scoped token/catalog rather than having to fetch it every time, but I 
feel that would have to include changes in Keystoneauth to supply it 
some cached data which tells it to not attempt to reauthenticate but 
rather trust the catalog/token supplied (does keystoneauth support 
that?). Because that reauth every command via Keystoneauth is actually 
what often takes longer than the actual API calls... We can also just 
throw catalog into that state/session file as json/yaml.

On 29/01/21 7:03 am, Stephen Finucane wrote:
> The definition for those opts can be found at [1]. As Sean thought it might be,
> that is using the default type defined in the parent 'Opt' class of 'str' [2].
> We don't expose argparse's 'action' parameter that would allow us to use the
> 'append' action, so you'd have to fix this by parsing whatever the user provided
> after the fact. I suspect you could resolve the immediate issue by changing this
> line [3] from:
>
>    self._methods = kwargs['auth_methods']
>
> to:
>
>    self._methods = kwargs['auth_methods'].split(',')
>
> However, I assume there's likely more to this issue. I don't have an environment
> to hand to validate this fix, unfortunately.
>
> If you do manage to test that change and it works, I'd be happy to help you in
> getting a patch proposed to 'keystoneauth'.
>
> Hope this helps,
> Stephen
>
> [1] https://github.com/openstack/keystoneauth/blob/4.3.0/keystoneauth1/loading/_plugins/identity/v3.py#L316-L330
> [2] https://github.com/openstack/keystoneauth/blob/4.3.0/keystoneauth1/loading/opts.py#L65
> [3] https://github.com/openstack/keystoneauth/blob/4.3.0/keystoneauth1/loading/_plugins/identity/v3.py#L338
>
>>> Jean-François
>
>