Amazon Web Services Working Group Agenda - 2022

[alinabuzachis]

Please leave a comment regarding any agenda item you wish to discuss. If you don't show up for the meeting, your item will be skipped. If your IRC nick is different from your Github username, leave that as well.
See https://github.com/ansible/community/blob/master/meetings/README.md for the schedule

Once an item has been discussed it should get checked off.

If you just want reviewers for your contribution join us on:

• IRC Channel: #ansible-aws
• Matrix Room: #aws:ansible.com

[marknet15]

Possible discussion points:

• Clarity on update path for module_utils in say amazon.aws and then modules consuming it in community.aws. Probably this will be less of an issue soon when a chunk of the modules get promoted to amazon.aws. But either way it might be a good thing to document.
• Tests stability, currently it's quite a regular occurance to have to run recheck / regate that slows things down, is there anything we could do to improve either through hardening of the tests themselves and or making the retries automatic ?

PRs for next community release ?

• ec2_asg_instance_refresh and ec2_asg_instance_refresh_info modules ansible-collections/community.aws#973
• sns_topic - Add tags and purge_tags options ansible-collections/community.aws#972
• elb_application_lb - support alb attributes ansible-collections/community.aws#963
• Refactor s3_bucket_notifications to support SNS / SQS ansible-collections/community.aws#940

Possible also:

• Add secret manager replication support ansible-collections/community.aws#827

[markuman]

backporting lifetime

• How long do we maintain backport releases?

stable-1 for example seems to be dead for me.

[jillr]

backporting lifetime

How long do we maintain backport releases? stable-1 for example seems to be dead for me.

I probably won't make the next meeting. for community.aws we can set any support cycle we like, for amazon.aws though we need to have the branches for anything that we still provide downstream Red Hat support for. stable-1 is still eligible for security fixes (but not feature backports).

[markuman]

• purge_tags default value

Let's undo this breaking change, but also look at how we want to do this. About 3 quarters of our modules that support managing tags default to purge_tags=True behaviour today (some even nuke tags if you don't set the tags parameter)

ansible-collections/community.aws#1064

• purge_tags must keep reserved tags
  • aws_secrets module tries to remove system tags. ansible-collections/community.aws#1146

  • System created tags that begin with aws: are reserved for AWS use, and do not count against this limit. You can't edit or delete a tag that begins with the aws: prefix.

  • tagging-py requires an addition parameter (with a default value) to keep the reserved tags. AWS is using them via cloudformation, asg etc
  • compare_aws_tags should ignore tags with the prefix 'aws:' ansible-collections/amazon.aws#817

[tremble]

@jillr Is 1.x eligible? I thought Ansible 2.9 had the modules still in ansible/ansible, so while we might need to backport over to the old repo but not necessarily into a 1.x release.

Which supported release has 1.x rather than 2.x+ ?

[tremble]

• 4.0.0 Release schedule - We have various deprecations slated for 2022-06-01, pull them in and release in June?

[tremble]

• 4.0.0 Release planning - Once we have a schedule let's decide on significant features (if any)

[jillr]

@tremble

Which supported release has 1.x rather than 2.x+ ?

AAP 2.1 included supported Execution Environment version 1.1, with amazon.aws 1.5

[mandar242]

• route53_info returns CamelCase, should have consistency along modules to use snake_case that can be used as a input to other modules directly, but modifying this might break existing playbooks for route53_info

[markuman]

• route53_info returns CamelCase, should have consistency along modules to use snake_case that can be used as a input to other modules directly, but modifying this might break existing playbooks for route53_info

does it break backwards compatibility, when the return values are not documentated yet? :)

imo it must be a general compliance that _info modules returns snake_case.

• and a follow up discussion: shall _info module output parameter names match the input parameter names?
  • anti-example: ec2_group and ec2_group_info
  • positive example: wafv2_ip_set and wafv2_ip_set_info

[tremble]

does it break backwards compatibility, when the return values are not documentated yet? :)

IMO, yes. Our docs have historically been rather lacking in completeness and accuracy when it comes to the return values, so consumers of modules have had no choice but to rely on what's been historically returned. One work around can be to add a new return value and return the new data structure in there.

[jatorcasso]

• lambda_info returns a dict of dicts as opposed to list of dicts. Should probably return list of dicts for consistency, but that would be a breaking change. Short term fix could be to add new return value representing the list, and deprecating the old

[tremble]

• Sanity checks now that Ansible 2.9 and 2.10 support has been dropped upstream...

[tremble]

Minutes from the May meeting:

Minutes (text): https://meetbot.fedoraproject.org/ansible-aws/2022-05-26/ansible_aws_community_meeting.2022-05-26-17.33.txt
21:15
Log: https://meetbot.fedoraproject.org/ansible-aws/2022-05-26/ansible_aws_community_meeting.2022-05-26-17.33.log.html

All topics up to this point were covered.

[jillr]

• ADR proposal
  We've started using Architectural Decision Records in the Cloud Control API code generator (https://github.com/ansible-collections/amazon_cloud_code_generator/tree/main/docs/adr)

As we make decisions that effect the amazon.aws and community.aws repos, we could adopt ADRs (or something similar) in these repos too. Things like the recent conversations about returns values, in addition to being recorded in the documentation, could also be codified as ADRs in the repo.
Questions:

1. Should we do this?
2. Where should ADRs be kept (ie; all in amazon.aws? in both repos? something else?)
3. Should we try to backfill previous decisions that have been made in irc, PR discussions, etc?

[tremble]

• Should we do this?

I'm a generally +1

• Where should ADRs be kept (ie; all in amazon.aws? in both repos? something else?)

In general I'd suggest either amazon.aws or something separate, and we move the WG agenda there too.

• Should we try to backfill previous decisions that have been made in irc, PR discussions, etc?

I think it would be valuable to try and capture the decisions we've made in the past, so at least some of the background is recorded "somewhere".

[tremble]

• Proposed module naming guidelines - (Module naming guidelines ansible-collections/amazon.aws#881)

[mandar242]

• route53_info returns CamelCase, should have consistency along modules to use snake_case that can be used as a input to other modules directly, but modifying this might break existing playbooks for route53_info

Fixed by ansible-collections/community.aws#1236

[tremble]

• Tentative release dates for 6.0.0. We have a number of deprecations slated for "a release after 2022-12-01". I suggest we pencil in a 6.0.0 release date of 2022-12-06 (as a gift from St Nicholas, and ~ quarterly) or 2023-03-02 as an "~6 monthly" release schedule.

[alinabuzachis]

This is continued in #687. From now on we will have one issue per year.