Parsed global parameters doesn't get passed to external aliases

[epl]

• When creating an alias (ie ~/.aws/cli/alias) to an external command, the parsed_globals variable (ie https://github.com/aws/aws-cli/blob/develop/awscli/alias.py#L274 ) is never passed to the child-process. As a result, information is lost. Hence, the child command is actively prevented from using certain command line parameters.

• Steps to reproduce:

  $ aws --version
  aws-cli/1.14.29 Python/2.7.14 Linux/4.13.0-25-generic botocore/1.8.33
  $ mkdir -p ~/.aws/cli
  $ cat > ~/.aws/cli/alias << "_EOF_"
  [toplevel]
  test = !echo "ENV:\n$(set | egrep -i 'foo' | sed -e 's@^@- @')\nARGS:"
  _EOF_
  $ aws --profile foo test subcommand --bar abc

• Actual output (note that all trace of the "foo" profile is lost):

  $ aws --profile foo test subcommand --bar abc
  ENV:
  
  ARGS: subcommand --bar abc
  $ aws --debug --profile foo test subcommand --bar abc
  2018-01-21 12:24:46,413 - MainThread - awscli.clidriver - DEBUG - CLI version: aws-cli/1.14.29 Python/2.7.14 Linux/4.13.0-25-generic botocore/1.8.33
  2018-01-21 12:24:46,414 - MainThread - awscli.clidriver - DEBUG - Arguments entered to CLI: ['--debug', '--profile', 'foo', 'test', 'subcommand', '--bar', 'abc']
  2018-01-21 12:24:46,414 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function add_scalar_parsers at 0x7fe1375b4750>
  2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable profile from instance vars with value u'foo'.
  2018-01-21 12:24:46,414 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function inject_assume_role_provider_cache at 0x7fe13454cc10>
  2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable profile from instance vars with value u'foo'.
  2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable credentials_file from defaults.
  2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable config_file from defaults.
  2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable profile from instance vars with value u'foo'.
  2018-01-21 12:24:46,414 - MainThread - awscli.customizations.assumerole - DEBUG - ProfileNotFound caught when trying to inject assume-role cred provider cache.  Not configuring JSONFileCache for assume-role.
  2018-01-21 12:24:46,414 - MainThread - botocore.hooks - DEBUG - Event session-initialized: calling handler <function attach_history_handler at 0x7fe133cfd850>
  2018-01-21 12:24:46,414 - MainThread - botocore.session - DEBUG - Loading variable profile from instance vars with value u'foo'.
  2018-01-21 12:24:46,414 - MainThread - awscli.alias - DEBUG - Using external alias 'test' with value: '!echo "ENV:\\n$(set | egrep -i \'foo\' | sed -e \'s@^@- @\')\\nARGS:"' to run: 'echo "ENV:\\n$(set | egrep -i \'foo\' | sed -e \'s@^@- @\')\\nARGS:" subcommand --bar abc'
  ENV:
  
  ARGS: subcommand --bar abc

• There are several possible solutions (mostly around https://github.com/aws/aws-cli/blob/develop/awscli/alias.py#L278-L283 ):
  a. Pass a serialised, sh-escaped (which makes non-sh/bash aliases difficult to write) parsed_globals via a new environment variable (eg AWS_CLI_ALIAS_PARSED_GLOBALS) which can then be eval'ed by the child-process. This data could also be in Base64-encoded JSON (though this is now getting complicated). We could also have multiple new variables (eg AWS_CLI_PROFILE) -- which starts to make it similar to solution 3c. Expected output then becomes:

  $ aws --profile foo test subcommand --bar abc
  ENV:
  - AWS_CLI_ALIAS_PARSED_GLOBALS='profile=foo color=auto paginate=1 command=test connect_timeout=60 sign_request=1 read_timeout=60 debug='
  ARGS: subcommand --bar abc

  b. Add it to the command-line. Unfortunately, we really need the unparsed-args. Else, we need to revert endpoint_url to --endpoint-url and I don't fancy dealing with duplicated logic. We could also modify ExternalAliasCommand.__call__ (and ServiceAliasCommand etc) to transmit the unparsed args (also see: https://github.com/aws/aws-cli/blob/develop/awscli/clidriver.py#L208 ). Expected output then becomes:

  $ aws --profile foo test subcommand --bar abc
  ENV:
  
  ARGS: --profile foo subcommand --bar abc

  c. For some parameters (eg --profile), modify the existing standardised environment variable (ie AWS_PROFILE) instead. However, there are no standardised variable names for most of the existing parameters. Expected output then becomes:

  $ aws --profile foo test subcommand --bar abc
  ENV:
  - AWS_PROFILE=foo
  ARGS: subcommand --bar abc

  Note that existing environment parameters exists for the following options only:

  • --profile to AWS_PROFILE
  • --region to AWS_DEFAULT_REGION
  • --output to AWS_DEFAULT_OUTPUT
  • --ca-bundle to AWS_CA_BUNDLE

  And none for (if this is the desired solution, I'd also like to hear opinions on appropriate environment variable names for the following, my recommendations in brackets):

  • --color (AWS_COLOR)
  • --no-paginate (AWS_NO_PAGINATE)
  • --cli-connect-timeout (AWS_CONNECT_TIMEOUT)
  • --no-sign-request (AWS_NO_SIGN_REQUEST)
  • --no-verify-ssl (AWS_NO_VERIFY_SSL)
  • --cli-read-timeout (AWS_READ_TIMEOUT)
  • --debug (AWS_DEBUG)
  • --endpoint-url (AWS_ENDPOINT_URL)

  A reason for the negatives is that by common (though not universal) Unix/Linux convention, a missing variable is treated identically to an empty string which is then interpreted as a boolean false. And given the existing default values for those variables, a AWS_NO_ name seems more appropriate.

• As an aside, git solves a similar problem by selecting solution c. There are also issues which would benefit from a consistent and complete set of environment variables (eg in Feature Request: set --debug via .aws/config #2007 the user could switch on --debug for all their aws-cli invocations simply by toggling AWS_DEBUG).

• Before I start coding up a solution, I'd like to hear from aws-cli maintainers what's likely to be merged. I want to avoid spending a lot of time coding/debugging, only for the patch to be rejected due to a difference of opinion at the very first step.

[dstufft]

Marking this as a feature request, thanks!

[yelhouti]

Any update on this please ? I would have loved to have AWS_NO_VERIFY_SSL for many use cases