New AWS Modules: botocore and boto3 are now production ready.

Archives Ansible Developer
1

This is a follow up to a prior RFC: https://groups.google.com/forum/#!searchin/ansible-devel/boto3/ansible-devel/BlruiipCVxk/KdvQI-wSSYUJ

I am advocating for a standard that new AWS module pull requests should be written in boto3, with an acceptable fallback to botocore should particular functionality not exist/be possible at the boto3 level.

Boto, botocore, and boto3 can all live together and do not conflict with each other. That being said, I’ll be working on extending our ec2 module_utils to include boto3 equivalent functions (and perhaps more) so the experience from a module development perspective can be consistent with the prior library.

Time permitting, I’d like to slowly but surely refactor existing AWS modules to use boto3 where it makes sense (like ec2_tag where boto currently cannot tag ELBs).

Other input appreciated.

Cheers,

2

A big +1 to this. It's been a question on my mind for a long time.

The question is, how to do it? Should we simply declare, "all new
modules starting today must use boto3"?

Should we wait for Mr. Davila to finish his work on ec2 module_utils,
and when it's done, make the switch?

--g

3

I think the module_utils piece is the first step. Once that is done, then we can make an official decree. The authentication/connection pieces of utils are key. Equally, old modules would be able to start using boto3 as well and it would be my suggestion that “new feature” prs for pre-existing modules happen via the boto3 library where possible.

4

With 2.0 nearly out the door, can we revisit this question?

There’s a few modules that I’d like to touch and the thought of a boto3 rewrite has crossed my mind.

Should we say now that from 2.1, new AWS modules should only use boto3? Should boto3 be required if you’re using any AWS modules post 2.0/2.1?

My answers to the above are emphatically yes!

5

I'm fine with new modules being boto3 only, but i want to keep
compatibility for existing modules

6

I agree it's a good idea to keep compatibility but how should we approach
adding new features to existing modules that are only possible with boto3?

7

make ONLY the new feature boto3 dependent and make it clear in the doc
description THIS FEATURE REQURIES BOTO3

8

Yep, exactly. This needs to be the standard now.

9

I created a PR for a AWS guidelines doc update