Load INI config as well as credentials

[devinivy]

When running aws configure it creates a config and a credentials file in ~/.aws. The config file includes useful information such as the region. It would make sense for the SDK to read this INI file to set the region automatically.

[AdityaManohar]

@devinivy There has been some conversation about sharing configuration across SDKs and the CLI. I'll add this as a feature request. In the meantime, FWIW, you can use the AWS_REGION environment variable to source your region.

[devinivy]

Cool! Just like to add (purely for clarity) that the SDK does load the INI credentials, just not the INI config, which is an awkward partial amount of support for sharing credentials across the SDK and CLI. For now I've had Opsworks write this configuration as JSON to the opsworks.js file. Thanks!

[lpetre]

I just ran into this too. It would be great if there was more consistency here. +1

[TimothyGu]

+1. @AdityaManohar would you accept a pull request adding this feature?

[lsegal]

@TimothyGu unfortunately, in order to address consistency, any decision we make would have to be an acceptable approach for our other SDKs, so a pull request would have to be reviewed by our other teams.

[TimothyGu]

@lsegal, makes sense. Is such a pull request at all possible? Is there some centralized issue tracker or should I submit the pull request to this repo only and ping all other SDK teams? Thanks.

[lsegal]

@TimothyGu there's no good central place. We've brought this up before to find out how we could probably share configuration-- the thing we all wanted to avoid was having configuration that was meaningful to one SDK but not useful (and thereby unsupported) by others. We tried to find a common set of options, but really the only one we could come across was support for region (which is already supported via AWS_REGION) so it kind of fell off the radar. I know this conversation has come up in other SDK issue trackers, so I will see what I can do about bringing this topic of discussion back up internally.

As for a PR-- I think it would be best to wait a bit and see what other teams think before trying to get something in. I'll try to keep this updated with any news. I generally agree that it would be great to share configuration across our tools!

[TimothyGu]

@lsegal cool thanks!

[Dudemullet]

@lsegal Sorry, I might not be understanding the problem or there may be way more underlying issues I don't understand but, isn't just adding variables to ~/.aws/config and ~/.aws/credential the same as having all the environment variables in a system?

By this I mean, if you're using the aws.Lambda part of the sdk, it will probably be relevant to pull in function_name from the global config. Whereas if you use aws.S3 maybe pull in bucket and body.

Just how right now the AWS sdk doesn't care that I have a NODE_ENV or CATALINA_HOME environment variables set, why would the Lambda sdk care you have a variable set for s3?

I'm just glad this isn't a closed issue and keep up the hope it will make it in some day. I'd be glad (as others have volunteered as well) to contribute a PR 😄

[lsegal]

@Dudemullet

Just how right now the AWS sdk doesn't care that I have a NODE_ENV or CATALINA_HOME environment variables set, why would the Lambda sdk care you have a variable set for s3?

The problem is that there is no well defined contract for what options in that configuration file mean to other tools right now. The point you make is valid, but the SDK will never touch a value in CATALINA_HOME since it is fairly outside the scope of this project. On the other hand, it is well within the scope of our SDKs to handle AWS configuration, and it would be reasonable to assume that if we supported global configuration from a file on disk, it would come from some kind of ~/.aws/config file.

It's worth noting that this issue is very unspecific about what the SDK should support in the config file, it only asks for support. If the SDK only supported region from the file, that would not satisfy the general request for being able to load configuration from this shared file. This raises a question of what it would mean to have general support for options in the file. Would it be considered a bug if the SDK supported region but not configuration of SSL options?

Note that it would be a breaking change to release support for a configuration file that supported the "region" setting today, only to eventually and silently start parsing out SSL options in the future. If we were to start supporting this file, we would have to be very clear on what we would and wouldn't support from the start. This is why it's important to nail down proper interoperability rules on a file whose main purpose is interoperability. This is actually the strategy we took with the credentials file, and it's why all of our tools support the full credentials file in a consistent manner.

Hope that explains a little bit more about the issue.

[Dudemullet]

Thanks for the explanation @lsegal 👍

[carlnordenfelt]

Any updates on this issue?
There are several inconsistencies between the JS SDK (or perhaps all SDKs) and the CLI. For example, the CLI expects region in AWS_DEFAULT_REGION whilst the SDK wants AWS_REGION. Same goes for profile where the CLI uses AWS_DEFAULT_PROFILE and the SDK uses AWS_PROFILE.
It's not a huge problem once you've discovered these quirks and created scripts for it, it's just a bit annoying when you stumble across it have to figure out why something on one end doesn't work on the other :)

I have written a few simple scripts to manage profiles and they deal with these inconsistencies too:
http://www.jayway.com/2015/09/25/aws-cli-profile-management-made-easy/

/ Carl

[LiuJoyceC]

We are still actively looking at this feature request. Closing this as we have another open issue (#1039) for this same feature request.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.