18:00:11 #startmeeting Ansible Community Meeting 18:00:11 Meeting started Wed Aug 18 18:00:11 2021 UTC. 18:00:11 This meeting is logged and archived in a public location. 18:00:11 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:11 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:11 The meeting name has been set to 'ansible_community_meeting' 18:00:11 #topic Agenda https://github.com/ansible/community/issues/539 18:00:11 abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping! 18:00:15 #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics 18:00:17 o/ 18:00:21 #chair cyberpear gundalow 18:00:21 Current chairs: cyberpear felixfontein gundalow 18:00:25 o/ 18:00:26 o/ 18:00:27 o/ 18:00:30 Howdy :-) 18:00:33 #chair tadeboro andersson007_ cybette abadger1999 18:00:33 Current chairs: abadger1999 andersson007_ cyberpear cybette felixfontein gundalow tadeboro 18:00:34 o/ 18:00:38 o/ 18:00:45 #chair briantist 18:00:45 Current chairs: abadger1999 andersson007_ briantist cyberpear cybette felixfontein gundalow tadeboro 18:00:48 oh shoot, it's wednesday isn't it? 18:00:48 o/ 18:00:54 I'm actually kinda here for once! 18:01:13 o/ 18:01:31 hey hey geerlingguy! long time no see 18:01:33 #chair dmsimard samccann geerlingguy 18:01:33 Current chairs: abadger1999 andersson007_ briantist cyberpear cybette dmsimard felixfontein geerlingguy gundalow samccann tadeboro 18:01:38 #topic Updates 18:01:38 #info ansible-core 2.11.4 has been released 18:01:38 #info Reminder: the community team is planning to do an Ansible Sprint / Hackathon during the Contributor Summit at AnsibleFest, more details forthcoming, message dericcrago if you have any questions or would like to get involved 18:01:44 o/ 18:01:48 #info If you don't have this meeting in your calendar, please import-by-url (don't download and add) https://raw.githubusercontent.com/ansible/community/main/meetings/community.yaml 18:02:30 #chair jill 18:02:30 Current chairs: abadger1999 andersson007_ briantist cyberpear cybette dmsimard felixfontein geerlingguy gundalow jill samccann tadeboro 18:05:22 #topic How to make meeting / discussion process more inclusive? 18:05:22 #info Discussion: https://github.com/ansible-community/community-topics/issues/38 18:05:22 no updates from me 18:05:25 Just wanted to announce that this topic exists, please add comments to it! Let's not discuss it today but next week. 18:05:40 sounds good 18:05:42 (if that's fine for everyone, I'll continue with the next topic soon) 18:05:47 This is really important to me 18:05:58 to me too 18:06:07 to many:) 18:06:12 #info Let's discuss this next week, and use this week to collect more ideas and think about them. 18:06:19 #topic Revise planned schedule for the release of Ansible 5 18:06:19 #info Discussion: https://github.com/ansible-community/community-topics/issues/37 18:06:22 #info Original PR: https://github.com/ansible/ansible/pull/75470 18:06:23 https://github.com/ansible/ansible/pull/75470 | open, created 2021-08-11T17:10:55Z by abadger: [WIP] Slip ansible 5 release to account for ansible-core slip. [needs_revision,WIP,support:core,docs,affects_2.12,docs_only]  18:06:25 #info New PR: https://github.com/ansible/ansible/pull/75529 (after discussion last week) 18:06:47 Hey all, can't stay today, kid is sick and I'm on duty. See you all next week. 18:07:34 cidrblock: Hope kid gets better soon. Everything will be in the meeting log. Feel free to add comments via https://github.com/ansible-community/community-topics/issues with any feedback you have 18:07:35 cidrblock: hope your kid will get well soon! 18:07:58 abadger1999: do you want to say something about this topic? 18:08:08 Yeah. 18:08:59 I put together a different schedule based on tadeboro's suggestion to keep the "last date for new collection submission" and "last date for new collection approval" the same as they were originally. 18:09:42 I read it and already gave a thumbs-up for this new one. 18:09:47 It gives more time between collection review's end and beta1 (the date when collection owners should no longer be pushing breaking changes in). 18:10:11 The only real drawback is another set of dates to remember. 18:10:12 which means we have two alphas after inclusion, before feature freeze comes with the first beta release 18:10:34 For me personally, I think that's an okay tradeoff; I like the new schedule better. 18:11:17 I like the new schedule, it also gives new collections some more time to adjust to changes after being accepted (like we had last time), and it gives reviewers more time after the reviewing's done to concentrate on their own collections before feature freeze :) 18:12:08 Does anyone want to discuss these more or shall we do a "Vote for Option A or Option B" ? 18:12:09 are there more comments on this? should we vote? 18:12:36 I would like "option A" and "B" to be referred to by PR, I'm going back and forth trying to figure which one is "new" still 18:12:45 18:12:49 is 24 09 a deadline for collection inclusion? 18:13:31 A is https://github.com/ansible/ansible/pull/75470/files 18:13:38 B is https://github.com/ansible/ansible/pull/75529/files 18:13:40 andersson007_: No, it isn't in either proposed schedule. 18:13:46 thanks tadeboro 18:13:59 VOTE: (A) Proposed schedule from last week (https://github.com/ansible/ansible/pull/75470/files), (B) proposed schedule from this week (https://github.com/ansible/ansible/pull/75529/files) with inclusion deadlines kept, (C) something else? 18:14:26 B 18:15:26 B (I'm ok with A though) 18:15:30 B 18:15:37 abadger1999: do you or anyone else know when? 18:15:37 In https://github.com/ansible/ansible/pull/75470 : last day for new collection submission is 2021-10-26; last day for approval is 2021-11-03. In https://github.com/ansible/ansible/pull/75529, last day for new collection submission is 2021-10-12; last day for approval is 2021-10-26 18:15:38 B 18:15:41 B 18:15:42 gotta run, sorry :( 18:15:42 A 18:15:47 bye geerlingguy! 18:15:49 B 18:15:51 abadger1999: thanks! 18:15:52 B 18:16:04 B 18:17:10 #chair 18:17:10 Current chairs: abadger1999 andersson007_ briantist cyberpear cybette dmsimard felixfontein geerlingguy gundalow jill samccann tadeboro 18:17:28 No view either way 18:17:29 abstain -- no strong opinion 18:17:39 cyberpear: do you prefer A for a particular reason ? 18:19:24 hmm, while there's a majority for B, we only have 5 x +1, 1 x 0, 1 x -1 from steering committee members 18:20:18 cyb-clock chimes: 20 minutes into meeting, 14 min on Revising Ansible 5 release schedule 18:21:09 maybe to be able to say after "I told you.." or something like that:) 18:21:12 (+1 = B, -1 = A, 0 = abstain...) 18:21:56 felixfontein: I'm okay calling for more votes in the ticket. It won't become a problem until we hit the first due date :-) 18:22:16 yeah, I was about to suggest we continue the vote in that ticket... :) 18:23:12 #info We need more steering committee member votes and will continue that in the ticket; right now we have 5 x B, 1 x A, 1 x no preference 18:23:29 #info A is https://github.com/ansible/ansible/pull/75470/files 18:23:36 #info B is https://github.com/ansible/ansible/pull/75529/files 18:23:42 (since that wasn't #info'ed yet :) ) 18:23:43 Yup, I'm happy with that. Especially given previous topic of increasing async discussion 18:24:18 does someone want to take the action to ping those who have not voted ? 18:24:28 should we continue with https://github.com/ansible-community/community-topics/issues/39 (Adding community-contributed examples to docs or a github repo), or should we discuss something else first? 18:24:37 cause, well, if they're not here, they might not know about it 18:24:51 dmsimard: Well volunteered, thank you :) 18:24:58 ok :P 18:25:01 lol 18:25:12 (and thanks for thinking about that) 18:25:12 dmsimard: well, they *could* read the minutes... ;) 18:25:23 s/could/should/ 18:25:45 :) 18:25:53 * dmsimard nods 18:26:55 we could also talk a bit how to make things more async to prevent such situations :) 18:27:27 or take a look at briantist's GH actions (https://github.com/ansible-community/community-topics/issues/40) 18:27:55 briantist's GH Actions are always exciting :-) 18:28:17 heh I'll just point out these are actions proper, not workflows 18:28:44 #topic Custom GitHub actions related to Ansible 18:28:50 #info Discussion: https://github.com/ansible-community/community-topics/issues/40 18:29:46 briantist: oh, nice. Thanks for sharing 18:29:48 briantist: in which scenario is "pull-ansible-test-images" supposed to be used? 18:30:17 I use it anywhere I'm using `ansible-test --docker` because pulling from quay.io is very slow on GHA 18:30:43 for 2.9 it takes almost 2 minutes to pull the default test image. It's closer 40s or so IIRC for newer versions 18:30:48 when things can be useful for a broader audience, they should be well-documented and shared 18:31:00 sorry. my opinion on previous item is weak 18:31:04 but when the tests themselves take under 2min, that becomes significant, and it's harder for me to compare test times on their own 18:31:11 ah, you mean the actions are used in workflows? (sorry for asking so stupidly, I'm always forgetting the exact GHA terminology :) ) 18:31:16 briantist: how does https://github.com/ansible-collections/community.hashi_vault/blob/main/.github/actions/pull-ansible-test-images/action.yml speed it up? 18:31:41 yep! exactly felixfontein , each step you do is an action, and the actions can (and often are) pulled from other repos 18:32:02 gundalow: it does not! but it shows me exactly how much time the pull takes vs the test itself 18:32:08 18:32:11 I want to see what I can do to speed up pulls, maybe caching etc 18:32:15 so it will also help me measure that 18:32:16 gundalow: I think it mainly separates pulling from running so you know how long the tests actually run 18:32:17 briantist: ah, gotcha. Thanks 18:32:27 briantist was quicker :) 18:32:40 I guess it makes the GitHub action log cleared as well 18:32:52 one thing I want to mention: I don't have a good sense how many collections are using GHA vs Azure/something else 18:32:59 so I also don't know how wide the audience is 18:33:18 but it is quite easy to put these in a repo, and then they can have their own tests, dev cycle, releases, and open up contribution 18:33:27 I think most use GHA, few use AZP, and few something else 18:33:35 but it probably only makes sense if someone (anyone) is interested in using them 18:33:53 the overall pattern might be nice anyway, even if these specific actions aren't wanted by anyone else 18:34:16 I think at the least, the one for installing collections from git would be used 18:34:33 maybe it would be nice to have an action which installs the required collections from galaxy.yml and tests/requirements.yml (which can be told whether to install them from git or galaxy) 18:34:35 I think at least one other collection is doing so (`community.dns` maybe?) 18:35:04 briantist: quite a few install from git (at least all I am involved in ;) ) 18:35:11 Roughly speaking 18:35:11 All of Ansible Network uses Zuul for CI 18:35:11 Anything that needs to test against multiple OS uses AZP 18:35:11 Everything else uses GHA 18:35:11 99% of gh/ansible-collections/ uses Zuul for Galaxy & AH release process 18:35:15 is there a recommended way of running tests? GH Actions vs AZP 18:35:23 hm that could be a paramter/feature maybe, reading from yml requirements 18:35:24 I generally like the idea of having some more specialized GHA actions that all collections could use 18:36:07 gundalow: thanks, i think you answered my question 18:36:24 andersson007_: Basically depends if you want to test against different OS 18:36:38 I have nothing in particular against GHA but what I would recommend is to try to keep the logic outside of GHA (say, in a script or elsewhere) and then just use GHA to run the thing -- this way people can use it with zuul, azp, jenkins or whatever 18:36:44 gundalow: ok, will know 18:36:57 my proposal would be to create a repository for GHA actions for ansible collections, and then we can have discussions to propose new ones, and PRs for adding them and discussing specific implementation details 18:37:01 dmsimard: sometimes that makes sense, other times not so much. But yeah, the codecov one does do that 18:37:09 Or if you want to test against something that isn't in Docker that you need AZP (as that's how we use spin up resources in AWS,Azure,MacStadium,etc) 18:37:49 felixfontein: multiple actions can exist in one repo, but the major downside of doing that is releasing, since you can't mark just one action as having breaking changes for example 18:37:55 ah, clear 18:38:19 so they are best kept in a single repo; if not for that I would much more strongly consider keeping them all together for ease of administration 18:38:31 each* in a single repo I mean 18:38:55 good point 18:38:56 I tend to preffer keep things transparent and keep try to keep things as platform-agnostic as possible. So Makefile + development env setup docs is what we usually use. 18:39:29 Caching is one thing different CI providers usually do inits own way, but for the rest of the stuff, we just stick to make + bash. 18:39:33 we could have a collection test tool package which has Python scripts that do these tasks 18:39:38 right, I try to strike a balance between using CI-specific magic and stuff that works everywhere but might be more work 18:40:05 then you can do `pip install xxx` and just use a run action to execute them in GHA, and whatever similar in some other CI system, or just use them in your Makefile 18:40:28 cyb-clock chimes: 40 minutes into meeting, 12 min on Custom GitHub actions 18:41:17 not all of this will be python, but point taken 18:41:58 I am not opposed to having some conveniece GHA actions if there is interest, but thus far any abstraction layer we added to our CI just made things harder to debug when things went haywire. 18:42:26 the actions I have so far are pretty small, for me packaging them that way is for re-use between jobs and/or making the workflow more readable, so it's up to anyone else if they wanna use an action from another repo or have a small bash/python snippet repeated 18:42:31 I already have some tools in community.internal_test_tools that could also be added to such a package (https://github.com/ansible-collections/community.internal_test_tools/tree/main/tools) 18:43:11 briantist: I guess all actions could be converted to "install package with pip, pass parameters to one tool from that package" 18:43:54 briantist: which would make the actions very thin wrappers for these tools, and would allow to use these tools also from other CI systems or from Makefiles 18:44:18 yeah that can be done, when the thing to run is python :) 18:44:44 the codecov one would be great that way, for anyone who wants to use the `ansible-test` -> flags stuff 18:44:50 you can also rewrite shell scripts as Python code, it's a bit overkill but makes it easier to install in a uniform way ;) 18:45:00 true 18:45:06 or maybe it could be *gasp* ansible playbooks 18:45:11 Install is probably the only sticking point. 18:45:35 (If rewriting shell => python, use the sh library ;-) 18:45:44 dmsimard: passing external parameters to playbooks is harder than to scripts (whether Python or shell) 18:46:16 if we're looking for CI that uses Anisble playbooks, we do have zuul ;) 18:46:49 I think it makes sense to make the GHA repos first, and if there's enough interest to pull out the internals into a separate package (enabling other CIs too), that could be done as a secondary step maybe 18:46:52 I guess for zuul it would be easier if these were roles (though I'm not *that* familiar with zuul) 18:46:57 felixfontein: happy to discuss about that some other time, I use playbooks as an interface a lot :p 18:47:33 but I'm also fine to keep these internal to the collection if there's not interest in them (some of them may not have wide appeal) 18:47:54 briantist: is there some step involved in eventually publishing these actions or something like that ? or would they be consumed out of that repository 18:48:08 maybe we should collect some proposals (of what we could do) in that issue, so we can think about them and potentially decide to implement one (or multiple) of them 18:48:51 the way actions work, the repo is the only thing you need. You can optionally "publish" them on the actions marketplace but that's just a way to browse (and it's like one click, it's very easy) 18:49:10 felixfontein: sure that sounds fine 18:49:38 I already published one action not related to ansible (but that I am using): https://github.com/briantist/ezenv 18:49:55 #info Collect some proposals in https://github.com/ansible-community/community-topics/issues/40, discuss them there and maybe implement one or more of them 18:50:10 ok, let's continue with open floor :) 18:50:12 #topic open floor 18:50:24 this time actually at :50, and not :58 or something like that ;) 18:50:30 felixfontein: :) 18:50:31 heh 18:50:41 achievement 18:50:52 do we want to cover contributor-based examples or save that to next week? 18:50:53 virtual high-five! 18:51:07 #info There currently isn't much listed as topics for Contributors Summit https://hackmd.io/AcI9TZf_SZqi7NG3ZyplnA#Day-2-Friday-October-1-2021 18:51:43 samccann: sounds like a good idea, will alicia be around then? 18:51:58 next week? I'd guess so yeah 18:52:27 #info Contributor Summit Tuesday: General what's this all about. recruitment drive, sessions on how to be a maintainer, hackathon, self-paced training 18:52:27 #info Contributor Summit Friday: More detailed discussion, like we usually have. possible breakouts 18:52:30 or we could use it as that 'async discussion' test issue :-) 18:52:32 #info Please look at Adding community-contributed examples to docs or a github repo 18:52:37 #undo 18:52:37 Removing item from minutes: INFO by felixfontein at 18:52:32 : Please look at Adding community-contributed examples to docs or a github repo 18:52:42 What would people like to be discussed on Friday of Contributor Summit/ 18:52:46 #info Please look at Adding community-contributed examples to docs or a github repo (https://github.com/ansible-community/community-topics/issues/39) 18:52:55 thanks felixfontein 18:53:51 gundalow: is Friday the 'traditional contributor summit' day? 18:54:00 felixfontein: correct 18:54:23 #info Bullhorn 32 is going out tomorrow, if you nave anything to add please do so by today https://github.com/ansible/community/issues/546 18:54:56 s/nave/have/ 18:56:00 cybette: you could #undo and correct to make it show up correctly in the minutes :) 18:56:52 #undo 18:56:52 Removing item from minutes: INFO by cybette at 18:54:23 : Bullhorn 32 is going out tomorrow, if you nave anything to add please do so by today https://github.com/ansible/community/issues/546 18:57:06 #info Bullhorn 32 is going out tomorrow, if you have anything to add please do so by today https://github.com/ansible/community/issues/546 18:57:09 thanks felixfontein :) 18:57:49 speaking of the bullhorn - that might be a way to bring in that async communication - to add issues/proposals we want feedback on to each bullhorn. (if that's not already in place) 18:58:45 IIRC there was at least the link to community-topics posted regularly there 18:58:50 samccann: good idea. though that will only work for discussions which will be long enough to not be over once the bullhorn is published :) 18:59:08 yeah there is a timing point to all this for sure :-) 18:59:39 cool! if there's nothing else, I'll close the meeting 19:00:09 #endmeeting