-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for AWS CLI v2 #3587
Comments
Now foo=bar will parse to {'foo': 'bar'}, which resolves an inconsistency that you can't tell how a shorthand snippet is parsed without also knowing the underlying types in the service model. There were some changes I had to make in the EMR tests, but that was primarily related to the expected messages in the error cases. CLIv2: aws#3587
The only special behavior now is if a param starts with file:// or fileb://. We can evaluate if we want some option to local paramfile functionality, but for now the simplified version is that there's no http/https auto-fetching, and file/fileb is always on. CLIv2: aws#3587
Highest on our wish list would be to not require entering a 2fa code every hour when doing cross-account role-assumption despite the assumed role allowing for a longer session duration. Is there any chance #2748 can be looked at? |
Yeah definitely. Reading over #2748 it looks like the main thing we needed was service side support for longer role durations, which has since happened (https://aws.amazon.com/about-aws/whats-new/2018/03/longer-role-sessions/). This should be possible now. |
That's awesome to hear. That's the one complaint I frequently get after implementing a centralized auth account. |
Now foo=bar will parse to {'foo': 'bar'}, which resolves an inconsistency that you can't tell how a shorthand snippet is parsed without also knowing the underlying types in the service model. There were some changes I had to make in the EMR tests, but that was primarily related to the expected messages in the error cases. CLIv2: aws#3587
Could the default setting on #2619 be flipped now in v2 so |
You should get inspiration from awless, it feels like a CLI actually designed for humans :) |
Would like to see more details on the actual/planned differences between version 1 and 2. |
PLEASE fix #2507 since the only blocker was "backward compatibility" |
@tkelman Yep, that's something we plan on addressing. There's also new functionality in docker that wasn't available when that command was originally created (IIRC) so I think it's worth looking at the docker credential helper protocol as well. |
Have you considered writing the tool in something like Go? Having a single, static binary you can deploy / install places, rather than having a dependency on the Python runtime would be amazing |
Hahaha, I just suggested this in #3605. :) |
Now that AWS finally supports U2F in the console, it would be wonderful if #3607 were included. |
Maybe (definitely) a bit petty, but I'd love it if |
@jacquestardie yes! #303 is the original issue. Even after years of using AWS CLI, I still regularly try |
@joffotron This is something we've seriously considered, but a re-write in Go is probably out of scope for V2. In particular the high level S3 command and the related library @jacquestardie I would also love to see this in V2, and it's definitely on our radar. |
The only special behavior now is if a param starts with file:// or fileb://. We can evaluate if we want some option to local paramfile functionality, but for now the simplified version is that there's no http/https auto-fetching, and file/fileb is always on. CLIv2: aws#3587
Now foo=bar will parse to {'foo': 'bar'}, which resolves an inconsistency that you can't tell how a shorthand snippet is parsed without also knowing the underlying types in the service model. There were some changes I had to make in the EMR tests, but that was primarily related to the expected messages in the error cases. CLIv2: aws#3587
Have you considered writing the tool in something like Haskell? Having a single, static binary you can deploy / install places, rather than having a dependency on the Python runtime would be amazing |
There's always pyinstaller. Can keep the code in python, and have a single binary that includes the python runtime. |
Support aliases (aside from just scripting them into .zshrc). Certainly following "some" direction from ElasticBeanstalk CLI, and awless. My apologies beforehand, if any of the following has been said/done/repeated.
Borrowing from how wonderful awless is:
Not implemented anywhere, or not well:
|
@oxidizeddreams, I really like the I would like to add another solution. What about using a hidden file ( |
To expand on the point @rnhurt brought up, another challenge organizations face is using IAM roles on the command line compounded with multi-account. Many organizations I work with use AWS SSO or custom SAML IdPs to federate access to IAM roles. Using the command line or SDKs from local or on-prem machines to leverage roles typically requires setting up IAM users/keys with AWS SSO partially resolves this with the interface that provides commands to copy/paste into a local terminal to assume the same role available in the console, but it can be prohibitive to require a customer to log into the console to get those instructions and can be difficult to successfully perform If there were some way to better support federation on the command line, I'd be all for it. |
@melusom Have you tried using awsprocesscreds with the |
@lorengordon I'll have to check that out. Thanks for sharing! |
So, what happened to the v2 idea? Is this dead? |
Not dead! 🎉 There's still a good amount of planning going on, and in terms of feature work, a lot of the work lately has been on installation mechanisms. Moving away from I do expect actual feature development to pick up over the next couple of months though. Thanks everyone for your patience on this. |
Moving away from pip? |
After spending a couple of days trying to get the aws2 cli and the credential-helper to play nice together on Mac, I'm wondering if this integration works at all in aws2? The git version is very recent, the OS X Keychain isn't involved in any way, everything is set up according to instructions, but I still get |
We have written a plugin for the aws cli v1 to allow us to have a custom authentication mechanism via a custom credential provider. It would be a shame if aws2 cli doesn't also support a plugin system. |
Hello all! Since the AWS CLI is generally available, I'm closing this tracking issue. You can follow along on any existing AWS CLI v2 issues, bugs, or feature requests with the Please feel free to open a new issue for anything that comes up with the AWS CLI v2. Thanks! https://github.com/aws/aws-cli/issues/new/choose |
Version 1.0.0 of the AWS CLI was tagged just over 5 years ago. In that time, a lot has changed. We've received tons of feedback from customers. We've learned what features customers enjoy, and what parts of the CLI we'd like to change. There are changes we've wanted to make, but needed to wait until the next major version of the AWS CLI due to either the backwards incompatible nature or the large scope of the change.
Well, we're here now. This issue is to track all the work for CLI v2. We wanted to do this work on GitHub right from the beginning. Even though we're in the early stages of development, community feedback will play an important role in its development.
If you have an idea for CLI v2, whether it's a new feature or a change we couldn't make in v1 of the AWS CLI, please feel free to open a GitHub issue and let us know. You can also go through any issue labeled as CLI v2 and +1 features that you'd like to see us implement.
Blog: https://aws.amazon.com/blogs/developer/aws-cli-v2-development/
The text was updated successfully, but these errors were encountered: