ECR subcommand: Resulting output includes deprecated docker login parameter

[brandongalbraith]

The output of aws ecr get-login --region us-east-1 is:

docker login -u <username> -p <password> -e none <container endpoint>

Docker reports Warning: '-e' is deprecated, it will be removed soon. See usage. when executing the above command produced by the awscli command.

The occurs with Docker version 1.11.0, build 4dc5990.

[jamesls]

Thanks for letting us know. Looks like we should just be omitting the "-e none" argument in the login command?

[brandongalbraith]

Excellent question! I'll test older docker versions to confirm, as an older
version might depend on that parameter being present and I wouldn't want to
break backwards compatibility.

[brandongalbraith]

Update: the "-e none" argument can be safely dropped when using the "docker
login" command.

EDIT: My information source was inaccurate ^

[jamesls]

I just wanted to give an update here. I spoke with the ECR team and they've mentioned that some earlier versions of Docker prompt for an e-mail if the '-e' flag is not provided. Removing this field from the default get-login output is not backwards compatible.

I think the concern is that if you're executing this command as part of some automated shell script, the script could now potentially hang.

I'll keep this issue updated as I get more info.

[dcosson]

Any update here? Docker 1.13 should be out soon.

UPDATE: it looks like now it won't be deprecated until 1.14? Even though the latest version of docker released a few days ago still tells me it will be deprecated in 1.13.

[rclark]

We recently encountered a scenario where:

• docker 1.12.6 was released as a security fix
• the ECS AMI that AWS distributes automatically applies security fixes, so
• our new EC2s started booting on docker 1.12.6 instead of 1.11.2
• our EC2 bootstrapping used a docker tag flag that was deprecated in 1.11 and removed in 1.12
• suddenly, without our having changed anything, new production EC2s were unable to boot.

This scenario can be avoided by disabling the automatic security fixes, but I think you should consider that the default ECS setup, alongside your desire not to remove this deprecated -e flag from the get-login response, runs the risk of disabling production systems when docker 1.13 (or perhaps 1.14) lands.

The attempt to petition docker not to remove the flag that has been marked as deprecated since 1.11 here seems pretty backwards IMO.

[PanJ]

Docker 1.13 has landed and the warning message is
Flag --email has been deprecated, will be removed in 1.14.

[debeers]

I cant push anything to ECS registry on production with this message:
Flag --email has been deprecated, will be removed in 1.14.
What`s going on? Somebody can help me please!

Im using eval $(aws ecr get-login --region eu-central-1) for login to registry and have this error:
Flag --email has been deprecated, will be removed in 1.14.

[gregeinfrank]

@debeers I've been using:

eval $(aws ecr get-login --region eu-central-1 | sed -e 's/-e none//g')

which works as a workaround

[jamesls]

We've added an --include-email/--no-include-email to the get-login command so you don't have to use sed anymore. For later versions of docker, just provide the --no-include-email flag. Let us know if you have any questions or concerns.

[oprearocks]

Have you thought about adding boolean option next to region, in ~/.aws/config instead of adding two new parameters to the get-login subcommand?

I see this new parameter addition as a temporary fix and as far as I'm concerned, having an option available in the tool's config file is more robust than having to remember to type parameter names correctly, at the command line.

Thanks.

[renatomariscal]

--no-include-email should be default now, as current versions of docker fails with email parameter.

[duginivijay]

Installing or upgrading AWSCLI doesn't prevent from throwing the error. We still got to use the command as below.

$ aws ecr get-login --no-include-email

[mattolenik]

Using awscli 1.11.138 on macOS and still have this issue. Docker version 17.06.1-ce-mac24 (18950)

[vsapronov]

I still experience this issue:
Docker version 17.09.1-ce, build 19e2cf6
aws-cli/1.11.13 Python/3.5.2 Linux/4.10.0-42-generic botocore/1.8.15

UPDATE: So the main problem was that --no-include-email option was not recognized hinting that aws-cli should be updated. The update would work only in pip3: #2676 (comment)

[dgpokl]

I know that typing --no-include-email works around this, but that is an extra thing to have to explain (indefinitely) to every new developer, and which they need to memorize. This issue also doesn't even make itself apparent until you Google the Docker error message.

While I totally get and agree with the plea made by @sentientmonkey to the Docker people that they don't break the API and instead allow -e none as a no-op, sadly they refused. So anyway, how much longer should the default option be to break for everyone who's not 2 years behind on updating Docker to avoid inconveniencing those who are that far out of date? The comment on the Docker discussion by @thaJeztah makes a good point that the API being given preference here is that of "unsupported versions of Docker with known CVE's".

I'd just like to get a sense of the aws-cli team's plans on this, not trying to demand the change immediately.

Additionally, I'd like to propose that aws ecr get-login print to STDERR this warning message every time it's invoked unless the --no-include-email option is used:

Warning: Unless you are using an old version of Docker (prior to 1.14), you must use the
  --no-include-email option to get-login because without that option, aws-cli targets
  the Docker 1.10 syntax by default, for backward compatibility reasons and this will throw an error
  in the current release of Docker.

This way, every developer who hits this error (i.e. every single developer who started using, or has updated Docker after 2017) can see what the problem is, and fix the issue themselves, and it requires neither Googling nor memorization.

[mattolenik]

Absolutely agree. This attitude of "let's leave it forever because backcompat" is part of how we get awful, crufty APIs over time. People are going to have to get used to the fact that a tool cannot stay stable forever. They're going to have to get used to the fact that they'll need to pin a specific version if they don't want behavior change.

Giving absolutely no error output and forcing people to Google it and find issue threads on GitHub is in no way acceptable and it's honestly a bit surprising we have to have these discussions in this day and age. We shouldn't accept poor user experience for developer tools just because developers use them. We're basically saying, "oh, but they're a dev, they'll figure it out." Usability of command line tools is just as critical as usability of any GUI app. Please let us stop dropping our standards because "they can figure it out."

[pre]

Just came here to say that after three years, --no-include-emailis still required and it needs to be discovered by Googling the error message unknown shorthand flag: 'e' in -e which leads here.

Cheers

[mattolenik]

Don't bother, they have no interest in ever fixing it. You can have AWS enterprise support and they'll just refer you to these threads rather than pushing product teams to fix their broken stuff.

[andrewlorien]

I'm migrating from a server which has the old versions of docker and awscli to a server which has new ones. The deploy scripts are written in bash. This is how i'm testing for the version and adding the flag:

DOCKER_FLAG=""
DOCKER_VERSION=$(docker -v | sed 's/Docker version \(.*\)\..*,.*/\1/g')
if [[ "10#$(echo $DOCKER_VERSION | cut -d '.' -f 1)" -gt 17 ]]; then
DOCKER_FLAG="--no-include-email"
else
if [[ "10#$(echo $DOCKER_VERSION | cut -d '.' -f 1)" -eq 17 && "10#$(echo $DOCKER_VERSION | cut -d '.' -f 2)" -ge 6 ]]; then
DOCKER_FLAG="--no-include-email"
fi
fi
$(aws ecr get-login --region $AWSREGION $DOCKER_FLAG)