4.0.0 release plan

[jillr]

Summary

Summary

Let's plan the roadmap for 4.0.0. Major or breaking changes that we know we want to include:

• The Ansible Content team expects to promote a number of community.aws modules to supported status. That initial list includes (but is not yet limited to):
  • rds_instance* (and probably other RDS modules)
  • ec2_asg*
  • ec2_eip*
  • elb_application_lb*

See also: The amazon.aws 4.0.0 plan.

Issue Type

Feature Idea

Component Name

community.aws

Additional Information

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:
None

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[markuman]

elb_application_lb*

Does this include also community.aws.elb_target_group?

The Ansible Content team expects to promote a number of community.aws modules to supported status

This time, we should take care about the pending issues and PR of the related modules.
So we should review and close what's maybe not relevant anymore and try to move forward and complete the open and ongoing PR of the related modules before moving.

... and complete the open and ongoing PR ...

And to instantly answer myself. That might be impossible :)

rds_

All pending PR are from @alinabuzachis and @marknet15, so I'll save the list here

• ISSUE: Cannot add instance to Aurora Cluster - (community.aws.rds_instance)
• ISSUE: Use community.aws.rds_instance module to create Aurora cluster
• ISSUE: rds_instance module should support adding IAM roles
• ISSUE: rds_instance reports changed despite no changes to the database
• ISSUE: Extend rds module to allow copying of rds snaphots cross region

ec2_asg

• PR: ec2_asg: add support for Spot allocation
• PR: Add asg refresh and info modules
• PR: ec2_asg: enable integration tests, change instance type to a type allowed by policy
• PR: Allow to provide instance requirements options to ASG module
• ISSUE: ec2_asg: add detach_instances feature
• ISSUE: AutoScaling Group tags module
• ISSUE: ec2_asg module does not check instance health status
• ISSUE: Autoscaling instance refresh API support

ec2_eip

• ISSUE: Unstable integration tests ec2_eip

elb_application_lb

• PR: add check_mode for elb_application_lb* & refactor integration tests
• ISSUE: Support "Drop invalid header fields" in elb_application_lb
• ISSUE: elb_application_ld modify rule: http-header not working
• ISSUE: elb_application_lb Updating Listener Rules Of Existing LB Fails After Edit
• ISSUE: elb_application_lb with empty security groups list behaves inconsistently on create/update

[markuman]

How do we handle the backporting of bugfixes between the repositories?
Some git patch magic?

[marknet15]

Is the move of modules just a mark of their maturity and support levels or is there any other criteria normally having to be met ?

[tremble]

Is the move of modules just a mark of their maturity and support levels or is there any other criteria normally having to be met ?

(Not part of the relevant team, but familiar with the general processes)

amazon.aws being the "Red Hat supported" collection, moving from the "community supported" collection to the "Red Hat supported" collection implies that the modules are in a state which can be supported. From previous migrations you'll notice that a certain amount of work will go into the targetted modules in order to get them to such a state. Minimal requirements will be things like (relatively) comprehensive integration tests and general maintainability (code quality).

The exact drivers of which modules get such treatment will be driven by business cases (customer demand and product 'story' balanced against level of effort).

As far as getting things onto the list is concerned: Probably the most effective option if you're a Red Hat customer and have business cases you'd like to see covered, then open up an RFE and get your business cases submitted.

[jillr]

elb_application_lb*

Does this include also community.aws.elb_target_group?

It probably will.

There's also a possibility we might slip this to 5.0.0 and include a much larger set of modules/services but I'm undecided on that (I'd sort of prefer to do one big group all at once, than two small groups back to back)

How do we handle the backporting of bugfixes between the repositories?
Some git patch magic?

Basically yeah. That's how we move the modules between repos while retaining their git logs.

[jillr]

There's two schedules we can take for the modules that Ansible would like to extend Red Hat support for, and we're interested in what the community would prefer.

1. Take the entire list of modules we're currently planning for and migrate them all at the same time (5.0.0). This limits disruption to a single release and reduces the number of deprecation dates (for redirects to be removed) to keep track of. We would ask for these migrations to block/set the 5.0.0 release date in this case. It's a substantial change to happen at once.
2. Migrate small groups of modules at a time, over the course of several major releases (4.0.0, 5.0.0, more would depend on the 5.0.0 timeline). The changes are smaller, but users have ongoing changes to track.

Migrations in this case mean moving the actual code (with git history) from the community.aws repo/collection to amazon.aws. We did this last year with a number of EC2 modules. The process for this is that first the Ansible Content team does work on every proposed module to make sure they're free of bugs, have working tests, and generally meet our code quality standards. The team is currently working on this. Once that's all completed we execute PRs to move the files between repos and add redirects in community.aws. Redirects (for example, community.aws.ec2_asg automatically redirecting to amazon.aws.ec2_asg in playbooks) would be in place for 4 major releases.

Our current list (subject to change) looks like:
rds_instance* (and probably other RDS modules)
ec2_asg*
ec2_eip*
elb_application_lb* (and ASG-related modules like elb_target_group)
aws_kms*
iam_role*
iam_user*
iam_policy*
lambda*
route53*

[markuman]

I vote for 1. .
For the enduser it is less annoying - imo.

[marknet15]

+1 definitely prefer one bigger change then lots of spread out smaller ones in this instance

[tremble]

I'm +1 to delaying the migrations, it also gives us the time to get a naming scheme sorted. I would also recommend that we branch stable-4 as early as possible after 4.0 is released, and any major changes land as early as possible in the post 4.0 release cycle to reduce the risk of delays that block a potential 5.0 release.

[markuman]

I close this issue, because 4.0.0 is released now.