Proposal of potential modules to be promoted from community.aws

[alinabuzachis]

Summary

Here is a proposal with some potential modules to be promoted from community.aws.

• elb_classic_lb_info
• autoscaling_group_instance_refresh(_info)
• sts_session_token (pairs nicely with sts_assume_role)
• secretsmanager_secret (pairs nicely with the lookup module)
• ssm_parameter (pairs nicely with the lookup module)
• aws_ssm

Let's review this list and possibly add more if you think so.

Issue Type

Feature Idea

Component Name

several

Additional Information

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[alinabuzachis]

cc @ansible-collections/cloud @tremble @markuman

[tremble]

My suggestions:

AuthN related:

• sts_session_token (helpful for authN and relatively simple)

Either general "Autoscaling" pieces:

• autoscaling_*
• ec2_placement_group
• ec2_launch_template

Or
Getting us closer to being able to set up a "base" AWS environment through amazon.aws:

• ec2_vpc_*

[mandar242]

@alinabuzachis @GomathiselviS opened PRs for migrating elb_classic_lb_info as discussed on slack, it already has a jira as well
#2272
ansible-collections/community.aws#2135
cc @tremble

[alinabuzachis]

@mandar242 @GomathiselviS I suggest developing a plan first and understanding whether any of the proposed modules can also be promoted. In the past, we agreed to move modules from c.aws to a.aws as blocks (as many as possible for each major release) and not as a single promotion per major release.

[markuman]

Getting us closer to being able to set up a "base" AWS environment through amazon.aws:

"base" is difficult to define. Is it just network, servers and dns?

Here is a proposal with some potential modules to be promoted from community.aws.

elb_classic_lb_info
autoscaling_group_instance_refresh(_info)
sts_session_token (pairs nicely with sts_assume_role)
secretsmanager_secret (pairs nicely with the lookup module)
ssm_parameter (pairs nicely with the lookup module)

I'm fine with those.

[GomathiselviS]

should we include the following?

community.aws.ec2_transit_gateway
community.aws.ec2_transit_gateway_info
community.aws.ec2_transit_gateway_vpc_attachment
community.aws.ec2_transit_gateway_vpc_attachment_info

[alinabuzachis]

After some research about the status, tests availability and complexity of each module, I’m more inclined to promote the modules (or as many we can) in list in amazon.aws 9.0.0:

• autoscaling_instance_refresh
• autoscaling_instance_refresh_info
• ec2_vpc_egress_igw
• ec2_vpc_peering
• ec2_vpc_peering_info
• ec2_vpc_vgw and ec2_vpc_vgw_info
• ec2_vpc_vpn
• ec2_vpc_vpn_info
• ec2_vpc_nacl
• ec2_vpc_nacl_info
• ec2_transit_gateway
• ec2_transit_gateway_info
• ec2_transit_gateway_vpc_attachment
• ec2_transit_gateway_vpc_attachment_info
• elb_classic_lb_info

Then if we still have time, we could also consider ec2_placement_group and ec2_launch_template. Otherwise, they can be added for release 11.0.0.

As for aws_ssm, the module is quite complex and there are more than 20 open GitHub issues for it. Therefore, promotion of the module will take a long time for refactoring and careful review. I am inclined to propose this module for promotion as an exceptional case in amazon.aws 10.0.0. I know that we agreed to promote modules once per year, but this will be an exception. Do you have any objections?

While, as the following list of module concerns, I suggest we add it to the list of potential modules to be promoted in amazon.aws 11.0.0:

• sts_session_token
• secretsmanager_secret
• ssm_parameter

I think it would make sense to create a roadmap once we agree on this, because it will make present and future planning easier.

[GomathiselviS]

The modules are promoted from c.aws to a.aws and will be available in amazon.aws 9.0.0