19:00:05 #startmeeting Ansible Community Meeting 19:00:06 Meeting started Wed Nov 30 19:00:05 2022 UTC. 19:00:06 This meeting is logged and archived in a public location. 19:00:06 The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 19:00:06 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:06 The meeting name has been set to 'ansible_community_meeting' 19:00:06 #topic Agenda https://github.com/ansible/community/issues/645 19:00:06 acozine, andersson007_, anwesha, baptistemm, bcoca, briantist, cidrblock, cyberpear, cybette, dericcrago, dmsimard, felixfontein, geerlingguy, gotmax, gundalow, gwmngilfen, ikhan_, jillr, jtanner, lmodemal, mariolenz[m], markuman, maxamillion, misc, nitzmahone, oranod, resmo, russoz, samccann, thaumos, zbr: The Ansible community meeting is starting now! 19:00:11 The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself. 19:00:13 o/ 19:00:14 #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics 19:00:32 #chair andersson007__ 19:00:32 Current chairs: andersson007__ felixfontein 19:00:41 o/ 19:00:42 o/ 19:00:46 #chair cybette_ acozine 19:00:46 Current chairs: acozine andersson007__ cybette_ felixfontein 19:00:54 * gotmax is kind of here 19:01:01 #chair gotmax 19:01:01 Current chairs: acozine andersson007__ cybette_ felixfontein gotmax 19:01:05 hi 19:01:15 #chair jtanner 19:01:15 Current chairs: acozine andersson007__ cybette_ felixfontein gotmax jtanner 19:01:35 o/ 19:01:42 The Matrix bridge broke today and kicked all of the Matrix people out of #fedora-devel, so hopefully we have better luck... 19:02:14 o/ 19:02:33 gotmax: oops, that's not good 19:02:38 there was a huge leave/join related to the bridge 1.5 hours ago 19:02:45 #chair samccann cyberpear 19:02:45 Current chairs: acozine andersson007__ cyberpear cybette_ felixfontein gotmax jtanner samccann 19:02:49 hi all 19:02:52 o/ 19:03:24 #chair oranod 19:03:24 Current chairs: acozine andersson007__ cyberpear cybette_ felixfontein gotmax jtanner oranod samccann 19:03:27 #topic Updates 19:03:39 felixfontein: Yeah, looks like it happened in all rooms 19:04:12 #info Ansible Core Holiday Release Schedule Update https://groups.google.com/g/ansible-devel/c/IQ7VPnw9yS8 19:04:16 I think Ansible 6.7.0 is scheduled for today? 19:04:24 s/today/this week/ 19:04:25 I think so too 19:04:49  s/today/this week/ | But it usually happens at the beginning of the week so meh 19:05:19 * gotmax is happy about the new schedule for 7... 19:05:47 me too :) 19:07:21 speaking of releases... does the PPA need any assistance? (it looks like it's missing 7, but I haven't dug into if their are reasons) 19:07:22 I guess one question about the 7.x.0 schedule is when to release 7.2.0, since ansible-core 2.14.2 will be released ~8 weeks after 2.14.1 19:07:52 dericcrago: I have no idea who is working on the PPAs 19:08:05 hi deric.crago !! let me check on the PPA status 19:08:10 dericcrago: Not sure either. I work on the Fedora and EPEL packaging :). 19:08:20 dericcrago: hi! nice to see you here! 19:08:34 Indeed! Welcome dericcrago. 19:09:10 felixfontein: Good point. We were in freeze, so it would be nice to get in a release sooner. 19:09:58 gotmax: 7.1.0 should happen next week 19:10:49 does anyone have a topic for today? 19:10:58 (or any announcements? :) ) 19:11:48 #info grafana.grafana and dellemc.unity will be included in Ansible assuming nobody objects (https://github.com/ansible-community/community-topics/issues/164, https://github.com/ansible-community/community-topics/issues/163) 19:11:52 * gotmax brb 19:12:21 #info There is a vote on removing community.fortios from Ansible 8 since it appears to be unmaintained (https://github.com/ansible-community/community-topics/issues/162) 19:12:31 oh 19:12:33 #undo 19:12:33 Removing item from minutes: INFO by felixfontein at 19:12:21 : There is a vote on removing community.fortios from Ansible 8 since it appears to be unmaintained (https://github.com/ansible-community/community-topics/issues/162) 19:12:49 #info There is a vote on removing cisco.nso from Ansible 8 since it appears to be unmaintained (https://github.com/ansible-community/community-topics/discussions/165) 19:12:53 sorry, got confused :) 19:13:03 felixfontein: tadeboro and anyone else involved, thanks for helping with inclusion reviews! 19:13:23 community.fortios also appears to be so, but we just started that process three days ago (thanks for that mariolenz[m]!) 19:13:34 Also, I have draft antsibull code to create a source dist that I need to cleanup and submit. 19:14:04 morning 19:14:20 There's another collection we said we'd start the removal for last week. 19:14:22 morning russoz[m]! 19:14:24 #chair russoz[m] 19:14:24 Current chairs: acozine andersson007__ cyberpear cybette_ felixfontein gotmax jtanner oranod russoz[m] samccann 19:14:25 Need to check which one 19:14:54 felixfontein: where's a vote on removing community.fortios from Ansible 8 ? i see only the topic 19:15:04 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 19:15:09 or it hasn't been started yet? 19:15:16 andersson007__: there isn't, I undid that #info 19:15:33 ah, ok, sorry 19:15:36 I'm talking about cyberark.pas 19:15:49 They still haven't fixed the release tagging issue 19:16:27 gotmax: yeah, in that case it's time to start that process 19:16:30 do you want to do that? 19:16:47 * gotmax needs to familiarize himself with the process 19:17:03 But yeah, I could do it 19:18:16 basically look at what mariolenz[m] is doing ;) 19:18:51 At this point, it'd be eligible for removal in Ansible 9, right? 19:18:55 i.e. start with a discussion topic in community-topics, and create an issue in the collection repo pointing to that. 19:19:02 if nothing happens in four weeks, we vote 19:19:43 Hi - I reckon this has been discussed before but I failed to keep track of it: how are we on the removal of unmaintained modules in collections (thinking specifically of community.general)? 19:20:09 hmm, I'm trying to find the removal doc, but I can't find it 19:20:19 https://github.com/ansible-collections/overview/blob/main/removal_from_ansible.rst 19:20:41 we should remove the whole c.network:) 19:20:41 ah, it was in overview 19:20:43 we have too many repos :) 19:21:08 heh, we do 19:21:18 i ping authors/maintainers from time to time, no one has responded 19:21:20 andersson007__: true, it is effectively unmaintained, but there's probably still quite some used content in it 19:21:54 felixfontein: that's true 19:22:05 For the collections violation requirements process, I don't think we wrote in an extra waiting process 19:22:44 gotmax: https://github.com/ansible-collections/overview/blob/main/removal_from_ansible.rst#process-3 - yes, it will be for Ansible 9 19:22:52 ah wait 19:23:01 true 19:23:10 https://github.com/ansible-collections/overview/blob/main/removal_from_ansible.rst#process-5 19:23:18 If X.0.0 will be released next, set Y=X+1. If X.0.0 has already been released, but (X+1).0.0 has not yet been released, set Y=X+2. 19:23:21 people reports issues, but what is the difference between not maintained modules in c.network or in any other collection (which we're kicking out when they are unmaintained)? 19:23:22 so still Ansible 9 19:23:22 It's eligible for removal after 4 weeks of not responding to the ticket about violations 19:23:38 But I guess we should wait another week or so before starting the vote 19:24:15 I was thinking about unmaintained the whole time, but it's violation of rules, not unmaintained (or maybe both :) ) 19:24:34 Yeah, I wonder if it is both... 19:25:49 answering my question: i think it'd require a lot of unnecessary work from our side:) 19:26:00 actually I think I have something to discuss a little, namely https://github.com/ansible-collections/community.network/pull/506#pullrequestreview-1189861386 - should we allow stuff to be moved from an Ansible included collection even if the destination is not in Ansible? 19:26:49 if users are informed in advance, why not? 19:27:43 especially if there's a maintained repo with the same content 19:27:57 instead of unmaintained one 19:28:05 andersson007__: maybe we should start an issue and ping everyone marked as a module/plugin maintainer, and explain that we plan to deprecate the collection, and if they want to either take over maintaining the whole collection, or move their stuff to someplace else, we help them with that, but otherwise the whole collection eventually gets deprecated and removed from Ansible, and is let to 19:28:11 die (more or less) 19:28:37 felixfontein: SGTM 19:28:45 i like the plan 19:29:13 in the past we wanted to avoid breaking users (by adding redirects to stuff not included in Ansible), but I think it's better to move stuff to places where it is maintained than waiting for more stuff to be included in Ansible... 19:29:26 agreed 19:29:40 anyway we kick out included collections 19:29:44 one question would be whether we want to allow moving stuff outside Ansible in general, or just for this case, resp. for community.network in general 19:29:49 true 19:30:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 19:30:10 good question 19:30:59 i think we could start with general collections like c.n and c.g 19:31:02 as special cases 19:31:10 normally it shouldn't happen 19:31:23 if stuff lives in a standalone repo 19:31:37 new people should maintain that repo 19:31:55 but i don't know:) 19:32:23 true 19:33:10 should we start a community topic on this, so we can eventually vote? I would suggest to only allow it for the large repos (c.g / c.n) for now, since for others its likely not needed, resp. potentially their maintainers just do it without asking us anyway :) 19:33:19 +1 19:33:40 +1 19:34:05 +1 19:35:08 ok, I'll create a topic for that 19:35:15 thanks! 19:35:26 russoz[m]: also asked about modules 19:35:31 unmaintained 19:35:37 from c.g 19:36:03 that one is more tricky, since c.g in general is still maintained :) 19:36:13 (for some definition of maintained) 19:36:27 true 19:37:08 imo, the long term goal should be to reduce as much centralized control of the colletions/modules as possible 19:38:24 :+1: 19:39:16 it didn't scale in the ansible/ansible repo, and i don't see the man|people-power issues being solved in c.g or any c.* collections 19:40:26 there are definitely pretty alive and active collections:) 19:40:40 yes, and a lot of not so alive ones :) 19:41:00 heh, it's a bell curve 19:41:02 yes but it's a kinda natural selection:) 19:44:09 threatening removal tends to draw out maintainers for content that's in use at companies. probably less so for hobby uses. GCP 19:44:21 c.mysql and c.postgres have 58 starts each:) against 500+ of c.general. Just statistics 19:44:39 starts? 19:44:48 yes 19:44:55 stars 19:44:57 oh 19:44:59 sorry 19:45:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 19:45:22 felixfontein has said something like this in the past IIRC, but I'd say having a "dead" ( however we define that) module/plugin in c.g. is better than having a completely unmaintained collection. 19:45:52 In c.g, PRs are reviewed. releases are made, general cleanups are done 19:46:01 ansible/ansible had a lot of "dead" modules too, and we got a lot of flak for it 19:46:20 the hard part is figuring out what exactly is dead 19:46:53 we should start trying to get some approximations on that, announce that these might get deprecated, and if nobody complains actually deprecate them 19:47:13 (basically what we talked about last week, or was it the week before that?) 19:47:26 what to do if integration tests start failing against new distros and nobody maintains them? should such modules be removed in this case? 19:47:35 "does anyone actually use this?" was a common question I had for modules 19:47:53 andersson007__: that happens often enough... I usually try a little bit to get them working, but not too much 19:48:15 andersson007__: deprecating them right away is probably not a good idea, especially if we have some indication that they are still used (community folks create issues or even PRs for them) 19:48:17 felixfontein: fully understood you 19:48:46 definitely not right away 19:48:58 but may be candidates 19:49:01 definitely! 19:51:22 another question: if we disable integration tests and then someone will fix something, everything will be green even if it actually broke something 19:51:48 true. usually I only disable them for the platform where they break, assuming they don't break too much at once 19:52:18 felixfontein: ah, in this case, it's ok i think 19:53:06 but in cases when it has more wide impact, not sure what to do 19:54:26 i hope it's not an often case in c.g 19:54:42 though c.n does not have integration tests at all:) 19:54:47 https://github.com/orgs/ansible-collections/projects/2 keeps track of all disabled tests 19:55:21 andersson007__: no, usually it mainly happens when new CI platforms are added, then sometimes a few tests have trouble... it only happens from time to time that existing tests just stop working completely 19:55:33 most of the times it's related to a new release of some tool 19:56:14 thanks for the link, added to bookmarks:) 19:56:31 I could imagine c.n is hard to test, since it runs against all that proprietary hardware 19:56:41 yep 19:57:01 exactly... 19:57:03 there are unit tests but it's not a replacement 19:57:28 actually for c.g, whether we declare a module/plugin as unmaintained should probably also be related to whether it has useful tests 19:57:29 really good addition though 19:57:34 (that are run in CI) 19:57:34 felixfontein: For the copr one, we just need a new test repository to use in the integration tests. I guess I can create one under my username. 19:57:55 there are ways around lack of proprietary gear, but it seemed like nobody wanted to make the effort 19:57:59 +1 to the statement about useful tests 19:58:06 gotmax: I was hoping that the module maintainer can take a look at this, I don't even know what copr is ;) 19:58:21 Copr is like PPAs for Fedora 19:58:44 and EPEL and CentOS Stream and ... 19:58:47 jtanner: some stuff in c.n has unit tests - how good / useful these are I cannot judge (except maybe some special extreme cases ;) ) 19:58:47 imo, lack of the ability to integration test should be used as criteria for not including the bits 19:58:55 gotmax: ah, good to know 19:59:58 jtanner: good point 20:00:00 https://github.com/vmware/govmomi/tree/master/vcsim ... we got away with smoke testing vmware with that for a long time 20:01:05 jtanner: it would be a lot easier if the 'cloud' plugins in ansible-test would be proper plugins, that would make it easier to test things like that without first having to get it into ansible-core... 20:01:24 true 20:01:28 (and yes I know that doing that in a pluggable way isn't easy :) ) 20:01:39 mattclay was always pretty busy though 20:01:54 I don't think that changed :) 20:01:57 prob not 20:02:11 we just got a huge improvement on container support for ansible-test 20:02:21 i saw, although i didn't understand the specifics 20:02:23 that was in the works for months now I think 20:02:57 it works a lot better than before, I haven't been able to run most tests on Docker for a longer time now, and podman only worked with some... now basically all included containers work with both Podman and Docker for me 20:03:15 (and this didn't happen by reducing the number of supported containers to a lower number :D ) 20:03:19 * russoz[m] back from an impromptu call 20:03:43 we also made this for infoblox https://github.com/ansible/nios-test-container 20:04:23 * andersson007__ has to go, bye and thanks! 20:07:37 sorry, I just got some emergency call, I need to check a down main server 20:07:45 can someone wrap up the meeting for me? thx :) 20:08:23 good luck felixfontein 20:09:09 Is there anything else to talk about today? 20:09:18 I was just typing that same question 20:09:27 heh typefaast 20:09:55 I think that's pretty much it 20:11:04 ok I'll endmeeting in a minute if nobody pipes in... 20:12:05 #endmeeting