17:33:00 <abuzachis[m]> #startmeeting Ansible AWS Community Meeting
17:33:00 <zodbot> Meeting started Thu May 26 17:33:00 2022 UTC.
17:33:00 <zodbot> This meeting is logged and archived in a public location.
17:33:00 <zodbot> The chair is abuzachis[m]. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:33:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:33:00 <zodbot> The meeting name has been set to 'ansible_aws_community_meeting'
17:33:15 <abuzachis[m]> #chair tremble marksman jillr
17:33:15 <zodbot> Current chairs: abuzachis[m] jillr marksman tremble
17:33:29 <abuzachis[m]> s/marksman/markuman/
17:34:12 <abuzachis[m]> #chair markuman jillr
17:34:12 <zodbot> Current chairs: abuzachis[m] jillr marksman markuman tremble
17:34:57 <abuzachis[m]> So looking at the #agenda https://github.com/ansible/community/issues/654
17:35:16 <abuzachis[m]> the first topic I see is #topic How long do we maintain backport releases?
17:35:24 <abuzachis[m]> #topic How long do we maintain backport releases?
17:37:37 <tremble> My suggestion: "officially" 2 releases, but with the obvious caveat that the cloud team can back portbas needed
17:39:09 <jillr> RH collection support is a bit more hand-wavy than "N releases", because it's "whatever major release what in a currently supported EE/version of AAP", which may vary depending on our collection release cadence
17:39:17 <jillr> so tremble's suggestion makes sense to me
17:39:21 <tremble> So when we release 4, stable-4 gets features, stable-3 gets bugs/security and dev happens on main
17:39:57 <abuzachis[m]> Make sense. Can we mark that as solved then?
17:40:23 <tremble> Yes, but with an action to update docs
17:40:49 <tremble> #action tremble to update docs with support policy
17:41:27 <abuzachis[m]> The next topic if from markuman
17:41:28 <abuzachis[m]> #topic purge_tags default value
17:41:34 <abuzachis[m]> #info https://github.com/ansible-collections/community.aws/pull/1064
17:42:15 <abuzachis[m]> s/if/is/
17:42:21 <tremble> Same principal applies to purge_* on a few other modules too...
17:43:45 <jatorcasso[m]> I know most modules with purge_tags defaults to True but is only used when tags are input (to wipe out tags use tags: {}). Can we make this the standard?
17:43:52 <jatorcasso[m]> or is there a better way
17:44:22 <markuman[m]> > It is common practice in Ansible AWS modules to have a purge_tags parameter that defaults to true.
17:44:23 <markuman[m]> generally I agree with it. But the aws_guidelines should mentioned that the default value must be false if the `purge_`parameter is introduced later.
17:46:02 <tremble> I'd rather we deprecate the default of purge=false once introduced, so it will switch to true
17:47:28 <markuman[m]> tremble: yes, that works for me also
17:47:34 <abuzachis[m]> Do we want to update the development guidelines?
17:48:19 <abuzachis[m]> I mean for future contributions
17:48:48 <tremble> I think we pick a preference, document and start cleaning up
17:49:15 <jatorcasso[m]> I have a follow-up question to this
17:49:40 <jatorcasso[m]> If purge_* is True, but the input tags are the same as current tags, do we want to return changed = True or changed = False?
17:49:54 <tremble> False, no change happened
17:50:47 <tremble> Historically testing has been hit and miss, so I'm sure we have bugs
17:51:31 <markuman[m]> the topic is close to the next one: `purge_tags must keep reserved tags `
17:51:31 <markuman[m]> shall we disuss in the same context?
17:51:31 <markuman[m]> if purge_ it True, but reserved tags a presented. do we return some extra information about it?
17:51:42 <abuzachis[m]> # topic purge_tags must keep reserved tags
17:51:48 <abuzachis[m]> s///, s/purge_tags/purge\_tags/
17:52:00 <abuzachis[m]> #info https://github.com/ansible-collections/community.aws/issues/1146
17:52:07 <markuman[m]> ...for those who wonder why purge_ doesn't delete `aws:....` tags
17:52:12 <abuzachis[m]> #info https://github.com/ansible-collections/amazon.aws/issues/817
17:54:12 <tremble> Not merged yet, are folks happy with this change in 4.0.0
17:54:38 <abuzachis[m]> Yes, I am!
17:56:18 <jillr> lgtm
17:57:18 <tremble> The PR as implemented ignores the aws: tags
17:58:32 <tremble> So, no "changed" if an aws: tag is left behind and nothing else changes
17:58:57 <tremble> Unfortunately the function doesn't have access to log a warning/debug message
17:59:56 <tremble> If we land this, I'll also land a changelog fragment in community.aws
18:00:55 <markuman[m]> maybe we should move the purge_tags documentation to amazon.aws doc_fragments?
18:01:04 <abuzachis[m]> Do we also want to update the documentation with this information?
18:01:31 <tremble> Which documentation?
18:01:52 <markuman[m]> ....that purge_tags doesn't delete reserved tags ...
18:02:06 <abuzachis[m]> exactly!
18:02:15 <tremble> tags: and purge_tags: can certainly be added as fragments with extra info if people would like
18:02:18 <markuman[m]> abuzachis[m]: imo yes. it's important
18:03:08 <tremble> #action tremble to add a tags/purge_tags fragment to amazon.aws
18:03:08 <markuman[m]> tremble: yes. imo it's better as to keep at lot of copies
18:04:11 <tremble> Anyone else care to update the guidelines with guidance around "purge" behaviour?
18:04:59 <tremble> Actually, I'll do it as part of the PR for the purge_tags fragment.
18:05:36 <tremble> #action tremble to update dev guidelines with info about default purge_* behaviour
18:06:01 <abuzachis[m]> Awesome! Thank you!
18:06:13 <abuzachis[m]> So we can go to the next topic then
18:06:17 <abuzachis[m]> #topic 4.0.0 Release schedule
18:06:48 <tremble> We've roughly discussed "after 2022-06-01", and deprecations have been merged in line with this
18:07:27 <tremble> I think the tagging PR should land, do we have any other major PRs to merge?
18:08:08 <tremble> I think community.aws has a couple of deprecation cleanups still to be written.
18:10:03 <abuzachis[m]> That works for me!
18:11:26 <tremble> Aim for 2022-June-23 ?  (4 weeks time)
18:11:47 <tremble> (possibly a couple of days later for community.aws)
18:13:00 <abuzachis[m]> The next topic is
18:13:03 <abuzachis[m]> #topic 4.0.0 Release planning
18:14:27 <tremble> I think we pretty much covered that.  Any major changes remaining?
18:15:07 <tremble> If not I'll close out the 4.0.0 issue and open a 5.0.0 issue
18:15:23 <tremble> Do we pencil in St Nickolaus to deliver release 5.0.0 (Dec 6)
18:15:55 <abuzachis[m]> Nothing else special come to mind
18:16:51 <abuzachis[m]> tremble: Work for me!
18:17:13 <abuzachis[m]> But isn't it too late?
18:18:12 <tremble> Our next round of deprecations currently (mostly) have "after 2022-12-01",
18:18:53 <abuzachis[m]> Ah ok, so makes sense then!
18:19:33 <tremble> We're doing pretty well at backporting features into the current "stable" release at the minute, and IMO as long as we don't need to land a breaking change for some reason, there's not much that *needs* a major release.
18:20:56 <jillr> what about doing 5.0.0 one quarter after 4.0.0 (so in Sept)?
18:21:12 <tremble> We can do that too
18:21:23 <jillr> that would include the module migrations (which we could then promote at AnsibleFest, and would let those newly supported modules be in AAP 2.3)
18:21:40 <tremble> I'm open to both, I'd like to pencil something in though.
18:22:34 <jillr> with my product hat on I'd like to get that out before Fest, but with my community hat if think that's too aggressive I understand
18:23:19 <jillr> I had planned to make time for at least 2 people from the team to work on the module moves this summer
18:23:46 <tremble> I don't think it's overly aggressive, but with a quarterly cadence we may want to think about how many releases between a deprecation and a breaking change.
18:24:24 <jillr> do we want a hard major release cadence?  or is it ok to say "we have a major release when there's breaking changes"?
18:24:48 <jillr> we could wait until, maybe, Jan/Feb to do a release with the Dec 1 deprecations, for example (just an idea)
18:26:59 <tremble> The advantage of pencilling in a date is we can land some of the breaking changes earlier in the release cycle
18:27:43 <tremble> With 3.0.0 we 'slipped' quite a bit trying to jam in all of the deprecation related breaking changes.
18:28:00 <jillr> true. I think we can safely say we'll probably always want a major release in roughly late Sept/early Oct (for AnsibleFest)
18:28:41 <jillr> (probably closer to September)
18:29:28 <tremble> If we land the stuff we *want* earlier rather than later, I suspect we'll meet our pencilled in dates with less "stress"
18:29:39 <jillr> definitely
18:30:31 <tremble> I'm good with pencilling 5.0.0 for say 2022-09-22 ?
18:30:49 <tremble> (I like to avoid planning changes for Mondays and Fridays)
18:31:10 <jillr> the former SRE in me approves  :)
18:31:42 <jillr> I'm good with that date, what about abuzachis[m]?
18:31:59 <tremble> markuman: Any opinion?
18:32:06 <abuzachis[m]> I'm also good!
18:32:21 <markuman[m]> tremble: I'm fine with that too
18:33:19 <abuzachis[m]> Do we want to talk about another topic or end the meeting?
18:33:42 <tremble> I'm good to continue, but we can close if others can't
18:33:52 <abuzachis[m]> I'm good too
18:34:05 <tremble> We missed last month too
18:34:46 <markuman[m]> than let's continue for 30 minutes?
18:35:12 <abuzachis[m]> ok, so next topic is
18:35:14 <abuzachis[m]> #topic consistency along modules to return snake_case
18:35:44 <markuman[m]> I see no cons here?
18:36:16 <abuzachis[m]> Several modules return CamelCase instead of snake_case
18:36:22 <tremble> Agreed, Someone needs to document what our standard is, and then how we handle cleaning up.
18:36:43 <tremble> (agree with markuman)
18:36:45 <abuzachis[m]> But how do we plan to deprecate the actual result and return snake_case?
18:38:14 <tremble> Multiple options
18:38:15 <tremble> 1) breaking change - which sucks for users
18:38:15 <tremble> 2) flag which changes returns - which isn't ideal, but does give the option for a deprecation message
18:38:15 <tremble> 3) return two different objects in parallel
18:38:57 <abuzachis[m]> The problem may arise when the CamelCase returned params are not structured in a result dict
18:38:59 <jillr> -1 option 1
18:38:59 <tremble> 3 Is kinda clean but means at some point there will likely be a silent breaking change
18:39:09 <markuman[m]> imo, 3 is the most graceful option
18:39:50 <markuman[m]> abuzachis[m]: that one needs to be identified...do we have an overview already?
18:40:32 <tremble> I've generally used 3 in the past.  2 exists in a couple of places, and we probably have examples of 1 from the boto3 migrations but I don't know of any (deliberate) examples
18:41:14 <abuzachis[m]> markuman[m]: Not really, If I am not mistaken @mandar find this is route53_info
18:41:35 <tremble> The one thing that 2. has going for it is it gives is a deprecation path that can output a message.
18:42:02 <tremble> At least until Ansible itself supports some form of deprecation annotation on return values.
18:43:57 <abuzachis[m]> s/find/found/, s/route53_info/route53\_info/
18:44:00 <jatorcasso[m]> so for [route53_info](https://github.com/ansible-collections/community.aws/blob/main/plugins/modules/route53_info.py), if we chose option 3, it would dump all return keys in both snake case and camel case
18:44:19 <tremble> jatorcasso: yes
18:44:49 <jatorcasso[m]> what would a deprecation message for that look like?
18:45:02 <abuzachis[m]> We should also define as well how we'd like to keep the return result for module probably, for concistency
18:45:16 <abuzachis[m]> s/module/modules/
18:45:35 <tremble> yeah, which is where the silent breaking change puts in an appearance...
18:45:38 <abuzachis[m]> s/module/modules/, s/concistency/consistency/
18:47:07 <tremble> I think jatorcasso's lambda_info example is another example of the same thing we need to think about.
18:49:03 <tremble> Suggestion - Someone draft a PR to update the guidelines with a straw man suggesting how they think we address the whole 'return value' + deprecation/cleanup thing should be approached and we come back to it in the next meeting?
18:49:42 <jatorcasso[m]> I can do that unless anyone else wants to
18:50:00 <abuzachis[m]> Awesome!
18:50:34 <tremble> #action jatorcasso to draft a PR proposing a solution.
18:51:02 <tremble> #topic should _info module output parameter names match the input parameter names?
18:51:28 <tremble> markuman: your topic
18:53:41 <markuman[m]> if they do, `_info` modules would act like a backup tool. furthermore, you can use them like a state file.
18:53:41 <markuman[m]> for example, we got a lot of traffic in our route53 records (>300 records that must be rolled out in some accounts). roll out took ages.
18:53:41 <markuman[m]> we keep the route53_info output in our git once and roll out just the diff if something has changed
18:54:48 <drich> Question.... I am trying to use amazon.aws.ec2_instance to determine if an instance exists and get all of the information about it. However, if I use that with "state: present" it throws the error: No default subnet could be found - you must include a VPC subnet ID (vpc_subnet_id parameter) to create an instance
18:54:51 <tremble> I like the idea in general, feeds back into the previous topic in how to cleanup and migrate
18:55:07 <drich> Should this be possible? or am I "holding it wrong"? :)
18:55:22 <drich> Here's an example of what I am trying: https://pastebin.com/LFNx2C9F
18:55:31 <markuman[m]> the same goes to securty_groups. where it is nearly impossible to do that, because the parameter output is completely different as the ec2_gruop module accepts
18:55:53 <tremble> drich: ec2_instance_info might be your best bet.  https://docs.ansible.com/ansible/latest/collections/community/aws/ec2_instance_info_module.html
18:56:42 <jatorcasso[m]> markuman[m]: speaking of, we should add `elements` to the return for ec2_group
18:57:02 <drich> Hmm.... let me give that a try instead. I think I tried it earlier in my testing, but I may have been fighting credential issues at that point...
18:57:37 <drich> from the docs I would think that ec2_instance would work... but I haven't dug into the code to see if I'm just reading them wrong or they don't work quite like I expect
18:57:45 <tremble> jatorcasso: Yeah, there's random stuff like that about.
18:58:21 <jatorcasso[m]> tremble: I can go through the _info modules and make sure they contain accurate info about what's returned
18:58:53 <tremble> jatorcasso: I'm recommend limiting your scope to amazon.aws for now ;)
18:59:21 <tremble> drich: It sometimes works, but ec2_instance is intended to create the instance.
19:00:09 <drich> thanks -- I will need that later -- the goal is "find the instance to ensure it exists, use ec2_instance to ensure it is running, then use some Windows foo to make sure some services are stopped before upgrade"
19:00:21 <drich> and then of course wash my hands since I touched Windows VMs :)
19:00:40 <tremble> markuman: I like the suggestion of trying to match, maybe we roll that into jatorcasso's proposal PR around what _info should generally return
19:02:14 <tremble> drich: There's also using ec2_instance "check_mode: True" but instances are complex so it probably doesn't handle the _info use case as well as it might.
19:02:31 <drich> Nice! ec2_instance_info works!!
19:03:04 <abuzachis[m]> So, switching to the next topic
19:03:05 <abuzachis[m]> #info lambda_info returns a dict of dicts as opposed to list of dicts.
19:03:24 <tremble> I think that's a subset of the previous two
19:03:26 <jatorcasso[m]> that can be marked as complete
19:03:31 <abuzachis[m]> Yes!
19:03:36 <abuzachis[m]> and the last one
19:03:38 <abuzachis[m]> #topic Sanity checks now that Ansible 2.9 and 2.10 support has been dropped upstream.
19:04:13 <tremble> Upstream no longer supports Ansible 2.9 and 2.10, do we care about sanity tests for them any more?
19:05:24 <tremble> I suggest we drop sanity tests (and ignores in main) for 2.9 and 2.10...
19:06:03 <abuzachis[m]> I agree doing that, but not sure what jillr thinks about!
19:07:23 <jillr> sorry I was multi-tasking  :)  /me reads
19:08:35 <jillr> it should be fine, but let us bring it up internally next week to make sure the team is ok with it?
19:09:06 <jillr> I don't see us building/suppporting a EE for AAP 2.1 with a 4.x collection though
19:09:34 <jillr> abuzachis[m]: are you working on Tuesday?
19:10:01 <abuzachis[m]> Yes, I do! Tuesday 31st?
19:10:16 <jillr> yep! could you please add the topic to the product management meeting?  :)
19:10:28 <abuzachis[m]> jillr: sure!
19:10:29 <tremble> The only 2.9/2.10 sanity test I know of that isn't in 2.11+ is the one complaining about deprecation versions/dates
19:11:53 <tremble> #agreed General consensus on dropping sanity tests for 2.9/2.10
19:12:17 <jillr> tremble: ack on the things being ignored, thanks
19:12:24 <tremble> #action abuzachis to follow up with Red Hat product management about potential internal side effects
19:13:20 <abuzachis[m]> Is there anything else we want to talk about?
19:13:29 <tremble> #topic Open Floor
19:13:58 <tremble> Nothing from me, markuman ?
19:14:22 <markuman[m]> neither from me
19:14:30 <abuzachis[m]> jatorcasso: ?
19:14:39 <jatorcasso[m]> nope im good
19:14:58 <abuzachis[m]> Ok so then we can end the meeting. Thank you very much!
19:15:11 <tremble> Thank  you all for your time today
19:15:15 <abuzachis[m]> #endmeeting