Switch to boto3?

[jantman]

boto3 is out and is where new development is supposedly happening, and is also the official AWS python SDK. Look into how difficult it would be to transition to using it.

[mr337]

We are transitioning all of our stuff from boto2 to boto3. Would recommend!

[jantman]

See also the Migrating from boto 2.x guide

[jantman]

I should do #112 and #114 before releasing this.

[jantman]

Before merging:

1. Refactor test data into a class/module
2. Look into how boto3 handles default regions. All of ALC lets the default region be None and passes this through to boto. With boto3, there's a change to the underlying environment variable use. I found this out by running awslimitchecker -vv -u -S ElastiCache after 32416b7, and got vastly different results from the latest release. It turns out that the new boto3 code is connecting to us-west-2. It appears that with boto2, if you set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, it completely ignores ~/.aws/credentials. With boto3, however, if you have a [default] section in ~/.aws/credentials and then export the key env vars, it still uses the region from ~/.aws/credentials.

[jantman]

The tests on the latest commit for this failed.

It turns out that the boto3/botocore code being called by result_fixtures.get_boto3_resource_model() is actually making an HTTP request to 169.254.169.254, the AWS instance metadata service, when running in Travis. This didn't seem to be happening when running locally. This happens when it creates the Session object.

So the boto3 Session.resource() calls botocore.session.Session.create_client() which, if aws_secret_access_key is None, calls Session.get_credentials(). That in turn calls self._components.get_component('credential_provider').load_credentials()

provider.load_credentials() for the first provider in Travis appears to go to InstanceMetadataProvider.load(). This goes to fetcher.retrieve_iam_role_credentials() which is utils.InstanceMetadataFetcher.

So... I think the real question is that InstanceMetadataProvider seems to be either not loading/being loaded in my local test (on phoenix), or is somehow exiting before pytest-blockage catches the request???

The key appears to be here where create_credential_resolver() adds the metadata provider. There's some stuff that comes from session config variables.

So I think that what's going on here is, based on that list in that function, is that the instance metadata provider is never getting called locally. I should add some instrumentation to my local botocore code to confirm this.

Another way around it might be that the docstring for create_credential_resolver() says, "Create a default credential resolver." Maybe I can somehow specify a non-default resolver?

Furthermore, am I sure that my function will even work without credentials?

https://github.com/boto/boto3/blob/1.2.3/boto3/session.py#L26 does have a param to pass in a botocore session, instead of creating a new one.

[jantman]

Ok, I reproduced the blockage failures locally. d'oh. I didn't move ~/.aws/config and it was sourcing credentials from there. Now, how to figure out how to get rid of the InstanceMetadataProvider (aside from possibly just mocking it out)...

[jantman]

Ok, I fixed the InstanceMetadata one by creating the botocore session directly, and passing in a session_vars dict that set metadata_service_num_attempts to 0. But I'm also seeing the same problem from retrieve_iam_role_credentials().

It looks like the simplest way to fix this is to export some bogus AWS credential environment vars, which will prevent any of the HTTP-firing credential providers from working.

[jantman]

Fix was merged in #119