Context:
https://discordapp.com/channels/485586884165107732/485596304961962003/644313703038189568
Might be related:
Temporary workaround:
https://discordapp.com/channels/485586884165107732/485596304961962003/644334026311598124
To get the above workaround working, I had to remove the mfa_serial = ... line from the profile I was using in ~/.aws/config
Might be solved by caching the session https://github.com/iterative/dvc/issues/2473#issuecomment-554191280 , but need to confirm.
Looked it up. This probably won't be solved by threadsafe caching s3 prop. I am surprised MFA work with dvc at all though.
Need to ask the user how MFA device is set.
Another user is experiencing this same issue. https://discordapp.com/channels/485586884165107732/485596304961962003/656143281163599885
We could solve it the same way we do it with passphrase-s for ssh, by using ask_password config option, but maybe we could auto-detect this somehow. Need to research this.
From https://docs.aws.amazon.com/cli/latest/topic/config-vars.html
If you specify an mfa_serial, then the first time an AssumeRole call is made, you will be prompted to enter the MFA code. Subsequent commands will use the cached temporary credentials. However, when the temporary credentials expire, you will be re-prompted for another MFA code.
need to take a closer look.
Might be related https://github.com/mixja/boto3-session-cache
It feels to me that we are not caching some boto session properly, thus preventing it from caching an access token.
@efiop your related lib says it is not needed anymore:
You no longer need this package as of botocore version 1.8.14, which now includes the JSON file cache structure traditionally used by the AWS CLI
Most helpful comment
To get the above workaround working, I had to remove the
mfa_serial = ...line from the profile I was using in ~/.aws/config