18:00:22 #startmeeting Ansible Community Meeting 18:00:22 Meeting started Wed Oct 21 18:00:22 2020 UTC. 18:00:22 This meeting is logged and archived in a public location. 18:00:22 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:22 The meeting name has been set to 'ansible_community_meeting' 18:00:37 thanks felixfontein :) 18:01:10 acozine: samccann: andersson007_: geerlingguy: aminvakil: ... everyone? :) 18:01:18 o/ 18:01:34 #chair gundalow cybette 18:01:34 Current chairs: cybette felixfontein gundalow 18:01:47 * felixfontein is still busy eating, so don't expect fast responses :) 18:02:09 Can't make it today 18:02:59 geerlingguy: no problem! :) 18:04:18 #topic agenda https://github.com/ansible/community/issues/539 18:05:13 I guess the main open topics are 1) new collections for 2.10.x / moving content, 2) new collections for 2.11, 3) nightlies, 4) BOTMETA, 5) sphinx extension 18:05:13 #info Proposals related to Collections have been moved to GitHub Discussions: https://github.com/ansible-collections/overview/discussions?discussions_q=category%3AProposals 18:05:24 for 3) and 5) we should wait for Toshio 18:06:05 1) I think we should do that 2) Yes though not sure about rules 3) If it works apply it 4) Need to agree aim (and if we care about docs) 5) probs wait as you said 18:06:27 The Bullhorn#12 has just been emailed out, which contains a summary of the open proposals 18:06:31 I guess for 1) and 2) the question is more how should we continue discussing this. you created a discussion for it :) 18:06:50 #topic new collections for 2.10.x / 18:06:54 #undo 18:06:54 Removing item from minutes: 18:06:56 #topic new collections for 2.10.x 18:07:17 1) Has there been enough discussion 18:07:17 2) Is the plan clear 18:07:17 3) Who needs to sign off 18:08:15 oh, I'm assuming we are only talking about moving content around from https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in no net-new code 18:08:51 well adding a new collection which contains code from a currently ansible-contained one might bring also new modulesplugins 18:08:55 +/ :) 18:09:08 o/ cybette and others 18:09:14 #chair svg 18:09:14 Current chairs: cybette felixfontein gundalow svg 18:09:33 hi svg! :) 18:09:34 gundalow: all three are good questions 18:09:44 hi everyone! 18:09:53 not used to these meetings, not sure how I can propose a topic? 18:09:54 I'm not sure how much input, resp. from how many different people we actually had. I think from not that many yet. 18:09:58 #chair aminvakil1 18:09:58 Current chairs: aminvakil1 cybette felixfontein gundalow svg 18:10:02 hi amin! 18:10:03 felixfontein: I *think* that's the same as c.general could (does) have new modules 18:10:16 hi felix! 18:11:21 https://etherpad.opendev.org/p/ansible-contributor-summit-october-2020-morning Line 58 18:11:32 I guess the final decision for 3) is up to Toshio, since he builds the thing :) 18:11:47 but it's not nice to shift all decisions to the RM 18:11:52 svg: you can propose it here https://github.com/ansible/community/issues/539 or use the "open floor" at the end to bring up a topic 18:12:43 gundalow: that's kind of https://github.com/ansible-collections/overview/discussions/117#discussioncomment-106136 18:12:45 guess i'm to late for the issue, I'll wait for the open floor, makes more sense too 18:14:36 I added the strawman proposal to https://github.com/ansible-collections/overview/discussions/117#discussioncomment-106136 18:15:18 o/ 18:15:19 that proposal would be compatible to the versioning plan of c.g, and in case 2.10.x allows new collections, this could be done 18:15:22 #chair resmo 18:15:22 Current chairs: aminvakil1 cybette felixfontein gundalow resmo svg 18:15:26 hi resmo! 18:16:05 > move things out of c.g after the last 1.x.0 minor release (see release schedule: end of November 2021) 18:16:05 That's ambiguous to me. Does that mean `git rm` (and add runtime.yml redirects) after the last 1.x.0 release? 18:17:26 gundalow: I think it means `git rm`, so they will be gone in c.g 2.0.0 18:17:39 I should have been more precise last week, would be less thinking now :D 18:17:52 haha, I appreciate you taking notes 18:18:36 I'm +1 to that 18:18:50 It does put the requirement on users to know their is a new collection and to use that 18:19:23 Though I think it's the only clean way since otherwise ansible-base's runtime.yml may point to something you don't have installed 18:19:29 I updated the proposal copy in https://github.com/ansible-collections/overview/discussions/117#discussioncomment-107974 18:19:37 I hope it's more precise now :) 18:19:54 yes 18:20:05 Yup, that's better 18:20:08 and c.g 2.0.0 has a breaking change, which can be mitigated by installing the new collections next to it 18:20:28 but that's ok since it's a new major release. it's unfortunate to not have a deprecation period, but since it's easy to mitigate, I think it's ok 18:20:35 resmo: svg aminvakil1 andersson007_ any thoughts on https://github.com/ansible-collections/overview/discussions/117#discussioncomment-107974 18:21:27 sorry, I forgot to ping lmodemal at the beginning of the meeting 18:23:06 Hello o/ 18:23:23 @chair lmodemal 18:23:41 #chair lmodemal 18:23:41 Current chairs: aminvakil1 cybette felixfontein gundalow lmodemal resmo svg 18:23:53 no idea whether you're interested in this meeting, but since acozine and samccann are often here as well... :) 18:24:03 Are their any downsized to this proposal? 18:24:12 typing, eating and thinking are not 100% compatible 18:24:16 Thanks for including me :) 18:25:30 if i understand this correctly, the proposal is to copy the modules to community.postgres and update them there except bugfixes, anyone using postgres.somemodule will be redirected to community.general.postgres_somemodule, but they can use the community.postgres.somemodule, am I right? 18:26:00 and remove them from community.general in 2.0.0 18:26:14 anyone using `postgres_user` will end up using the (semi)unmaintained `community.general.postgres_user` module 18:26:17 there's no redirect from community.postgres to community.general; the modules will mainly live in community.postgres, but be kept for compatiblity in community.general 18:26:17 * acozine is in a training session 18:26:24 (until 2.0.0 is released, then they're gone) 18:26:41 yeah, this might make confusion. 18:26:55 true. fortunately the timeframe is not that long (2 months) 18:27:13 november 2021? 18:27:15 hum, so potential thing is would people still raise PRs against community.general? Maybe not if we `git rm` from main, and the plugin is only in `stable-1` branch 18:27:27 or 3 months, depending on when the collections are released and added to ansible 2.10.x 18:27:31 aminvakil1: november 2020 :) 18:27:35 sorry acozine and I are in training. I'll scroll back when it's done 18:27:41 felixfontein: `end of November 2021` (typo?) 18:27:56 acozine: samccann: no problem :) 18:28:10 did I write 2021? 18:28:15 oh 18:28:16 etherpad and copypasted 18:28:17 lol 18:28:18 thanks :) 18:28:20 in github it has been written 2021 18:28:21 only just noticed 18:28:37 aminvakil1: just changed it :) 18:30:07 so for 2-3 months (more like 2, because the collections have to be set up first) c.g will get no new features, and maybe not every bugfix for these modules, but then ansible 2.11.0 is released which will contain c.g 2.0.0 which has redirects 18:30:29 (the only suffering people will be the Ansible 2.9, they will have to adjust their FQCNs manually) 18:31:49 (and they only have the problem when upgrading fom c.g 1.x.y to 2.0.0) 18:32:23 No going to impact that many people negatively in that time window 18:32:36 I agree 18:32:44 For CI speed it would be good to migrate docker and postgres 18:32:55 migrating out postgres would also help Tower installer 18:33:08 Is there anything else that we know about, was there are k8s collection? 18:33:41 I would also prefer to migrate everything that causes c.g to have collection dependencies 18:33:55 I see from #117 rockaut is in favor of migrating postgres as well 18:33:55 i.e. kubevirt (I think someone already works on that?), and the handful of other modules/plugins 18:33:56 ah, yes 18:34:22 https://github.com/ansible-collections/community.general/issues/354 18:35:02 we could add a community.google collection (main problem are missing maintainers). that together with a kubevirt collection would remove all non-ansible dependencies 18:35:23 for the ansible.* dependencies, we could vendor the few utility functions they include 18:36:02 they only need some helper functions like validate_ip_address, validate_ip_v6_address, ismount 18:36:26 OK, lets do this 18:37:34 we have to cut a bit on the maintainer requirements though 18:37:53 how do you mean? Making new collection/repos that no one will look at? 18:38:25 yes, especially community.google might be kind of unmaintained 18:39:12 we had this requirement somewhere "at least two maintainers" 18:39:17 (for new collections?) 18:39:29 yup, in collection checklist 18:40:43 I would say that this rule can be broken if the content is not new. Because the same people will still look after it no matter if it is part of the c.general or c.google (man, c.g is not unique ;) 18:40:48 it shouldn't be a problem for community.postgres, might become a problem for community.docker, and probably is a problem for community.google 18:40:58 tadeboro: oh, that's a nice point 18:41:08 tadeboro: true! I like that 18:41:32 technically we aren't making the situation worse (zero maintianers for X in c.g == zero maintainers in c.x 18:41:35 ) 18:41:45 as long as someone takes a bit care to make sure CI is still running, and allowing people who want to to contribute, I think it should be fine 18:42:05 gundalow: true, except that there's a new separate CI ;) 18:42:41 luckly I should have some new people starting next month, so maybe I can take responsibility for that 18:42:54 should we also move some stuff out of community.network? it currently depends on check_point.mgmt and fortinet.fortios 18:44:08 I guess so 18:44:23 I'd also propose community.routeros (moved from community.network), since that part is actively maintained 18:45:23 maybe we should create tracking issues for every move-out 18:45:35 and maybe also ask whether others also want to move to their own collection 18:45:59 Do we want to encurage others at this stage? 18:46:05 given deadlines? 18:46:19 good question 18:46:39 the main deadline is "a few 2.10.x releases before 2.11.0" I guess 18:46:55 and "a few weeks before c.g/c.n 2.0.0" 18:47:01 i.e. beginning of January 18:47:51 let's say the collections need to be done by end of december 18:48:02 +1 18:48:04 then we have a bit of wiggle-time 18:48:22 Sounds like a plan 18:48:39 for that we need a decision on the question "new collections in 2.10.x" though :) 18:48:44 If we can define the steps we can then farm this out to multiple people 18:49:19 I'm happy to help with all of them 18:49:31 +1 to "We will allow content to migrate from an existing https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in to a new one, as long as all dependencies are contained in https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in" 18:49:35 Thanks felixfontein :) 18:49:50 (of course I'm happy if I don't have to do all of them :) ) 18:50:09 I can help with some 18:50:48 btw, about CI for the new collections, should they use github actions, azure, or something else? 18:50:56 svg: did you have a topic? 18:51:06 especially for postgres and docker having something like shippable would be better than github actions 18:51:14 but that's not urgent. let's talk about svg's topic first! 18:51:27 not so much a topic, as some feedback 18:51:36 #topic Open Floor 18:51:42 I prepared a bt of text: 18:51:45 svg: The floor is yours 18:51:49 So I tried following discussions here tonight, but was overwhelmed by a;; those different collection namespaces that were mentioned. Came here after having a short discussion in a private group with some long time ansible users, and cybette asked us to give feedback here. 18:51:51 Basically, all those namespaces are confusing as hell. Now we understand this is al new, and lots of things are being tried, and need some time to sort out of course. 18:51:53 Now this made me wonder if there are specific rule, about how to know about 1/ official namesapces, 2/ community namespaces 3/ vendor specific namespace, and 4/ possible others. I know the theory a bit, and community.* is clear, but e.g - I think it was mention ed in the lates Bullhorn - "community.kubernetes collection is going to move to kubernetes.core" - again, confusing. 18:51:55 Not asking for the specific answer here, but I guess what I wanted to achieve, is stressing how confusing this is, even for Ansible experts - which perhaps don't work with collections on a daily basis yet, and propose this should get special attention in documentation and communication in general. 18:52:11 HTH :) 18:53:17 svg: Firstly I appreciate the feedback, especially on things we are doing that clearly confuse people 18:53:35 cybette, feel free to give some nuance, as you followed the discussion I refered to, I might miss a thing. 18:54:04 svg: As far as I know, there is no guidelines about the namespaces at all (and some vendors had quite some troubles selecting the "right" one according to the partner engineering team). 18:54:08 is tonight = today and here, or tonight = last week at the the community summit? 18:54:09 svg: you've covered the main sentiments well 18:55:14 I think tonight = today and here 18:55:27 `"community.kubernetes collection is going to move to kubernetes.core"` I think that's a good example of where we ever talk about changing namespaces we should assume zero background knowledge and therefore must give a one line summary, then link back to something more details that explains the what/why of naming 18:56:11 svg: As far as the moving things around goes, I expect things to stabilize a bit once there are no more large collections such as community.general. 18:56:15 I only heard about community.kubernetes -> kubernetes.core a couple of days ago (last week probably?) and have no idea on why it is done 18:56:18 gundalow, 👍 18:56:54 I'm mainly concerned on shuffling around the community.* space :) 18:56:58 tadeboro,yes, that is too what I expect, and I expect that will become easier in the near future. 18:58:12 But I can imagine the pain of an early adopter that moved to FQCNs just to be forced to do another grep over her stuff once every few weeks. 18:58:16 I recently read an issue I think, about some repo having older roles/modules, that were deprectated, and another namespace where the newest were to be found. Pretty sure that will be very confusing, if noticed at all, and I expect lots of people to pick the wrong one. 18:58:17 a couple of events I'd like to mention: 18:58:42 not only early adopters of ansible, anyone who needs to start using some new bits 18:58:49 (oops sorry matrix just burped out a bunch of messages, I thought people have stopped talking) 18:59:49 svg: if you mean the procedure for moving stuff I mentioned (i.e. https://github.com/ansible-collections/overview/discussions/117#discussioncomment-107974), then early adopters will not miss much (and for only a short time) until they upgrade to ansible 2.11.0 19:00:25 svg: Ugh, I forgot about the stuff that is only accessible via the FQCN. 19:00:41 svg: it is mainly problematic for Ansible 2.9 users, which don't have the redirects 19:01:11 tadeboro: that's no problem for 2.10+ users, since there will be redirects. it's a problem for 2.9 users though. 19:01:40 but the only way to avoid this is not to move any content, until 2.9 is gone 19:01:50 and then more people will have used the 'wrong' FQCNs 19:03:28 I may be missing something, though what's the 2.9 concern? 2.9 doesn't have runtime.yml, so if you are using collections you need to specify what you want to use 19:04:04 gundalow: yes, and if 2.9 users start using c.g with the modules in there, they put the FQCNs like community.general.postgres_database in their playbooks/roles 19:04:14 and once community.general 2.0.0 comes out, they suddenly stop working 19:04:34 gundalow: On 2.9, if you need something new, you need to use FQCN for that stuff. And if the FQCN changes, you need to update your playbooks. 19:04:34 since community.general.postgres_database is no more, and the redirect only works with ansible-base 2.10+ 19:05:21 felixfontein: I though c.g 2.0 would have runtime.yml pointing to c.postgres.x 19:05:23 that's why I wouldn't use 2.9 for collections :) but unfortunately 2.9 is pretty popular, and RH is not helping by skipping 2.10 :) 19:05:33 gundalow: it has, but ansible 2.9 doesnt know about runtime.yml 19:05:46 ansible-base 2.10+ knows about it, but not ansible 2.9 or earlier 19:07:00 the problem is that if we tend 2.9 users, we screw 2.10+ usres, and if we tend 2.10+ users, we screw 2.9 users 19:07:10 except if we don't move anything, then everyone's happy 19:07:15 except us :) 19:09:16 where us = the people who develop and maintain the collections 19:10:41 I wouldn't prioritise 2.9+collections over 2.10+ 19:11:02 felixfontein: collections that were created from ansible 2.9. The rest of us have less problems because we have a stable FQCN from the get go. 19:11:05 me neither. we shouldn't just ignore them either, though. 19:11:42 tadeboro: true :) even though also other collections might want to move stuff or rename themselves, and they'll then face the same problems 19:11:44 Yeah, I just heard a few days ago Ansible 2.9 being called LTS, sooooo ;) 19:11:56 exactly... 19:12:10 and nitzmahone didn't like the idea of backporting routing to stable-2.9 :) 19:12:18 that would also solve that problem for us 19:13:27 anyway, the longer we wait with shuffling stuff around, the more it hurts for 2.9 users, since there will be more of them that are actively using FQCNs in a lot of places 19:14:04 But I tend to agree with gundalow here: I think it is OK for community to prioritise ansible 2.10 over 2.9. 19:14:16 I vote we move the content out of c.g and c.n as we talked about today 19:14:26 And yes, the sooner things can get their semi-permanent home, the better. 19:15:07 should we vote on this somehow? or have a public poll (outside this small group)? 19:16:31 I am not sure if public poll is the best way to go since most people do not have enough information to make an informed decision about this. 19:17:17 yep, I agree 19:17:26 I'm OK to proceed 19:17:33 I would say that current maintainers should decide on a compromise that makes their life bearable while not screwing up the users. 19:18:15 And if I put myself in the end-users shoes, current compromise of leaving a few things broken on 2.9 is acceptable. 19:19:18 especially if a simple `community.general.postgres_` -> `community.postgres.postgres_` transformation can be used to rewrite names 19:20:11 If at all. As said before, if the moves are done sooner, most users will not even know about the move at all. 19:20:30 can this be implemented on ansible-lint, so that some users can do the fixes when redirection is still there? 19:20:37 I need to drop off now 19:20:42 Thanks everybody 19:20:52 thanks gundalow!!! 19:20:55 couple things to add 19:21:06 #info Free webinar next week (Oct 28) "Introduction to Testing Ansible Collections" https://steampunk.si/webinars-training/intro-testing-ansible-collections/ 19:21:10 led by tadeboro :) 19:21:18 #info Ansible Hacktoberfest 2020 (Oct 30) https://organize.mlh.io/participants/events/3936-ansible-hacktoberfest-2020-virtual 19:21:29 bring your own beer and halloween costume if desired 19:21:34 we didn't have a hack day after Contributor Summit last week, so this can be considered in lieu of the hackday 19:22:02 the Hacktoberfest site requires you to create an account. if you prefer not to, just add your name to the etherpad here: https://etherpad.opendev.org/p/ansible-hacktoberfest-2020 19:22:07 #info Ansible Hacktoberfest etherpad https://etherpad.opendev.org/p/ansible-hacktoberfest-2020 19:22:33 aminvakil1: not sure, probably would need a big hack and it has to be done very fast, because once the move has been done and people upgraded the collections, it's too late 19:22:37 hmmmmmmmmmmmmmmmmmm 19:22:37 I just got an idea 19:23:10 felixfontein: yep 19:23:22 how about adding redirects to meta/runtime.yml, but keeping the old modules around and marking them as deprecated? that will cause some sanity errors (because meta/runtime.yml and module disagrees), but it will continue to work for 2.9 users and they get a deprecation warning, while 2.10+ users get the redirects 19:24:17 it will be a bit more tricky for the modules depending on another collection, since the dependency will be gone, but I think it's doable 19:24:28 hmm, except that galaxy import will break since ansible-doc won't work when doc fragments are missing 19:24:31 hrm 19:24:49 felixfontein: This thing might need to live for quite a while though. So think twice before accepting that kind of maintenance burden ;) 19:25:12 tadeboro: yep, I know 19:25:31 tadeboro: considering the problems caused by doc fragments, it doesn't sound very good 19:25:45 (if it's just adding some sanity/ignore-*.txt entries, it would be fine) 19:27:06 hmm, I guess it's time to stop for today 19:27:18 let's think about this and continue next week? 19:27:37 +1 for next week. 19:27:42 I'll try to write up some things in https://github.com/ansible-collections/overview/discussions/117#discussioncomment-107974 19:28:04 ok, thanks everyone! 19:28:07 #topic open floor 19:28:19 if you have something else, write in the next two minutes :) 19:28:40 oh I thought the previous topic was already open floor 19:29:16 I think this week we forgot a lot of #topic and #info lines... 19:29:33 not sure if it's element or matrix but I'm getting the messages in spurts and it's really confusing. sorry for my flood of messages earlier. 19:29:33 Technically, it was. But the rules are there to be broken ;) 19:29:34 but actually you're right 19:29:59 cybette: no problem :) 19:30:47 I #info-ed the stuff so it should be fine. just in the wrong order and interrupting people :P 19:31:32 nothing else from me, thanks 19:32:02 ok :) 19:32:04 #endmeeting