Amazon Web Services Working Group Agenda - 2022

alinabuzachis commented 2 years ago

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 commented 2 years ago

Possible discussion points:

[x] 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.
[x] 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 ?

Possible also:

[x] https://github.com/ansible-collections/community.aws/pull/827

markuman commented 2 years ago

Unfortunately I probably won't be able to attend on our first meeting. It's week 1 after our quarantine and we have to find our rhythm here first.

markuman commented 2 years ago

backporting lifetime

[ ] How long do we maintain backport releases?

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

jillr commented 2 years ago

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 commented 2 years ago

[x] 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)

https://github.com/ansible-collections/community.aws/pull/1064

[x] purge_tags must keep reserved tags
- https://github.com/ansible-collections/community.aws/issues/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
- https://github.com/ansible-collections/amazon.aws/issues/817

tremble commented 2 years ago

@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 commented 2 years ago

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

tremble commented 2 years ago

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

jillr commented 2 years ago

@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 commented 2 years ago

[x] 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 commented 2 years ago

[ ] 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.

[x] 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 commented 2 years ago

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 commented 2 years ago

[x] 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 commented 2 years ago

[x] Sanity checks now that Ansible 2.9 and 2.10 support has been dropped upstream...

tremble commented 2 years ago

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 commented 2 years ago

[ ] 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:

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

tremble commented 2 years ago

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 commented 2 years ago

[x] Proposed module naming guidelines - (https://github.com/ansible-collections/amazon.aws/pull/881)

mandar242 commented 2 years ago

[x] 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 https://github.com/ansible-collections/community.aws/pull/1236

tremble commented 1 year ago

[ ] 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 commented 1 year ago

This is continued in https://github.com/ansible/community/issues/687. From now on we will have one issue per year.

ansible / community

Amazon Web Services Working Group Agenda - 2022 #654

backporting lifetime

backporting lifetime