Closed alinabuzachis closed 1 year ago
Possible discussion points:
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:
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.
stable-1
for example seems to be dead for me.
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).
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
purge_tags
must keep reserved tags
tagging-py
requires an addition parameter (with a default value) to keep the reserved tags. AWS is using them via cloudformation, asg etc@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
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
- [ ] 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.
_info
module output parameter names match the input parameter names?
ec2_group
and ec2_group_info
wafv2_ip_set
and wafv2_ip_set_info
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.
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.
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?
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".
- [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
This is continued in https://github.com/ansible/community/issues/687. From now on we will have one issue per year.
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:
#ansible-aws