18:00:12 #startmeeting Ansible Community Meeting 18:00:12 Meeting started Wed Mar 30 18:00:12 2022 UTC. 18:00:12 This meeting is logged and archived in a public location. 18:00:12 The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:00:12 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:12 The meeting name has been set to 'ansible_community_meeting' 18:00:12 #topic Agenda https://github.com/ansible/community/issues/645 18:00:12 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:16 #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics 18:00:19 #topic Updates 18:00:20 o/ 18:00:21 o/ 18:00:22 o/ 18:00:23 o/ 18:00:35 #chair cyberpear dmsimard andersson007_ jillr 18:00:35 Current chairs: andersson007_ cyberpear dmsimard felixfontein jillr 18:00:36 Thanks 18:00:40 #chair gundalow 18:00:40 Current chairs: andersson007_ cyberpear dmsimard felixfontein gundalow jillr 18:01:39 #info The collection link feature is active on the devel docsite! 18:02:16 #info ansible-core created the stable-2.13 branch and bumped devel to 2.14.0.dev0 18:02:18 o/ 18:02:19 o/ 18:02:20 o/ 18:02:36 #chair samccann cybette 18:02:36 Current chairs: andersson007_ cyberpear cybette dmsimard felixfontein gundalow jillr samccann 18:03:30 #info Contributor Summit is in two weeks! \o/ 18:03:32 any other news? 18:03:53 felixfontein: maybe include a link to https://hackmd.io/@ansible-community/contrib-summit-202204 18:04:04 no particular updates from me 18:04:12 o/ 18:04:59 #chair dmsimard 18:04:59 Current chairs: andersson007_ cyberpear cybette dmsimard felixfontein gundalow jillr samccann 18:05:14 #info Community Summit infos: https://hackmd.io/@ansible-community/contrib-summit-202204 18:05:17 #chair briantist 18:05:17 Current chairs: andersson007_ briantist cyberpear cybette dmsimard felixfontein gundalow jillr samccann 18:06:15 thanks felixfontein dmsimard , I just got back to my desk and wasn't fast enough with the contrib summit info :) 18:08:08 glad to see the IRC info at the bottom for those not on matrix 18:08:08 so, dmsimard suggested to talk about https://github.com/ansible-community/community-topics/issues/84, and there's of course also the collection removal topic we could continue from last time 18:08:17 (there's a PR for it btw: https://github.com/ansible-collections/overview/pull/201) 18:08:49 cyberpear: indeed! 18:08:51 definitely in favor of not pinning patch versions 18:09:25 cyberpear: there's a big difference IMO between pinning (`==`) and specifying a lower version (`>=`) 18:09:39 #topic Dependency of Ansible on ansible-core 18:09:44 #info Discussion: https://github.com/ansible-community/community-topics/issues/84 18:10:06 specifying a lower version when that version is the latest is kinda sorta pinning :p 18:10:13 perhaps, rather "ratcheting" 18:10:16 like >=2.12.3 but there's no 2.12.4 18:10:17 #info Old decision was made in https://meetbot.fedoraproject.org/ansible-community/2020-07-01/community_working_group_meeting.2020-07-01-18.04.html, see also https://github.com/ansible-community/antsibull/issues/94 18:10:34 dmsimard: it's only pinning now, until a new one comes out 18:11:20 right, and I wonder to what extent it is necessary since >=2.12.0 has essentially the same effect 18:11:26 we have several aspects here that are different from other package dependencies: a) correctness of the Ansible combined changelog, b) correctness of the Ansible docsite 18:11:50 /me reads antsibull#94 18:11:57 dmsimard: it does not, see briantist's and mine comments 18:13:32 I suggest to also read the old discussion (https://meetbot.fedoraproject.org/ansible-community/2020-07-01/community_working_group_meeting.2020-07-01-18.04.log.html) 18:14:05 Nice pr https://github.com/ansible-collections/overview/pull/201 felixfontein , thanks! added couple of comments, thanks for reminding 18:14:34 felixfontein: to be clear, I mean that if you're doing a fresh installation with pip, whether the requirement is >=2.12.3 or >=2.12.0, you'll still end up with 2.12.3 (if that is the latest) 18:15:02 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:15:44 not following it all, but at the high level - Ansible 5.5.1 needs to be the same whether I do a pip install or something else from Fedora etc. If the package has the same version on different distros, it should be the same versions for all the underlying bits and bobs (core, collections, etc) 18:15:52 felixfontein: thanks for hunting back that old discussion, it predates my arrival so I need to catch up on it 18:16:14 dmsimard: that's true. but if you installed Ansible 5.0.0 when it came out, and now do `pip install ansible==5.5.0`, you end up with ansible-core not being upgraded with your proposed dependency relation 18:16:54 same discussion; my opinion hasn't changed since then... can't believe it's been over 1.5 years since then! https://meetbot.fedoraproject.org/ansible-community/2020-07-01/community_working_group_meeting.2020-07-01-18.04.log.html#l-50 18:17:09 samccann: since we don't pin the ansible-core dependency, it's not really true either... if I do `pip install ansible=5.0.0` now after having had installed Ansible 5.0.0, ansible-core will not be downgraded 18:17:55 cyberpear: indeed, in a couple of months it will be two years of the new Ansible community package :) 18:18:11 given we've combined both the docs and the changelog, that sounds problematic felixfontein . 18:18:42 samccann: it is... 18:19:27 I wonder whether we should decouple Ansible and ansible-core more. if there wouldn't be the ansible.builtin collection, it would probably a good solution, but the existence of ansible.builtin complicates things a lot. 18:19:35 it was unpopular at the time, but we can split them up. (core docs in one place, collection index/guides in another 18:20:00 what will happen to the ansible.builtin docs? 18:20:13 they would be in core. 18:20:47 oh I see.. .so the 'collection index' docsite wouldn't include builtin unless we pulled it in specially. And again, we'd hit the same problem of potential mismatch 18:21:13 yes, and the list of all plugins/modules would also skip ansible.builtin then 18:21:37 that would probably be the most painful part of it, at least for me personally :) 18:21:37 and yeah, search wouldn't find them either (site search) 18:22:01 I have some homework to do to read past discussions, we can move on to another topic if you'd like :p 18:22:28 in any case, there are some complicated UX related things that need to be solved first before the packages can be properly split apart :) 18:22:50 kinda related thought I've had lately (and was probably discussed before I was so involved), but I wish all of the `ansible.builtin` stuff was actually maintained as its own collection. The collection could be `ansible.core`, and it will still be pulled into core and included as `ansible.builtin`, but it would allow updates to those modules and plugins that are faster than core's release cycle, and could be optionally 18:22:50 called as `ansible.core.whatever`. 18:22:55 it's hard for me to know how many users face this potential mismatch of core vs Ansible version 18:23:34 (of course it would have to exclude things that are not true modules/plugins and work in the executor, like `include_role` and such) 18:24:14 Worth noting that there's nothing preventing users from installing whatever version of ansible-core and then picking whichever versions of collections -- there's users "stuck" on ansible-core 2.11 (due to py38) and using collections from ansible 5, for example 18:24:26 samccann: ^ 18:24:52 dmsimard: true, but these users should not expect that the Ansible docsite gives them an accurate image of their installation :) 18:24:59 yeah, fair 18:25:27 yeah what Felix said. 18:26:14 Depending on how often we think this sort of thing happens though, is where we decide whether it's worth trying to fix or provide a way for users to find what they have locally reflected in docs 18:26:14 If someone wants to raise a dedicate issue for moving `ansible.builtin` into it's own collection, then we can use that for discussion with Core Team. There maybe technical reasons why it might be difficult though. 18:27:02 yeah, I imagine the most pushback will be around testing, since it will have to be special-cased one way or another 18:27:06 I think the core team already had lots of discussions about this, and I think some of the arguments have already been documented in random places (probably mostly IRC discussions) 18:27:15 as a user, I would really appreciate it though 18:27:43 felixfontein: I don't doubt that :) I imagine there were many hours burned on that and that probably nobody wants to revisit it haha 18:29:45 yup, I'm sure there has been discussion, though if we could get something in GH, they we can point to that in the future 18:30:05 yep, something referencable would be nice :) 18:30:08 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:30:12 (maybe we already have that and forgot about it though...) 18:31:28 briantist: to recall tough memories:) 18:32:26 ok, should we talk about collection removal? or something else? 18:34:15 (or documented ansible installation mechanisms, future of the ansible package, ...) 18:35:14 we could also talk about splitting up the antsibull package 18:35:49 for future of the package, we've received lots of feedback via https://www.reddit.com/r/ansible/comments/tjfbqx/future_of_ansible_package/ 18:36:23 ah, I tihnk we should link that from the discussion 18:36:30 I wasn't aware of that reddit discussion for example 18:36:39 I did link to it in one of my replies though it may be non-obvious 18:37:40 I can abuse my powers and edit the initial post and put it there? 18:38:02 dmsimard: ah, now I see... the link title wasn't long enough ;) 18:38:25 no worries, it's ok to link to it explicitly 18:39:08 I wonder whether we should make it easier to create your own package with exactly the collections you want 18:39:34 felixfontein: would it require more than a fork of ansible-build-data ? 18:39:40 gundalow: do you mean on reddit or the issue. If it's about the issue, feel free to edit of course. 18:40:01 On the issue, will do, thanks andersson007_ 18:40:11 the main issue with that is that we need to care more about dependencies then, right now we basically enforce by contract that all dependent collections are around - and somtimes fail, see community.kubevirt :) 18:40:12 cool, thanks! 18:40:44 dmsimard: not really, just start with an ansible.in file and list the collections you want to have 18:40:44 felixfontein: I think that is the intent for https://github.com/ansible-community/antsibull/pull/270 though it never pan out 18:40:48 the ltrim dillema! 18:41:42 dmsimard: that was more a kind of sanity check I think. to allow users to specify their own collections we'd probably need some more complete dependency resolution, like `ansible-galaxy collection install` does it 18:41:43 (wow that issue is exactly one year old) 18:42:02 s/issue/PR/ 18:42:56 felixfontein: could/should we run "ansible-galaxy collection install" instead of the home made downloader, then ? 18:44:32 dmsimard: last time I tried that, it was **a lot** slower (since it had to do all the dependency resolution, and galaxy's API is sloooooooooow) 18:45:01 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:45:54 felixfontein: be careful, that way lies 'resolvlib' 18:46:00 also for our use-case - building Ansible - it's a huge overkill, since we basically require that no dependency resolution needs to be done if we always pick the latest versions 18:46:26 bcoca: I didn't say I want to implement it, I'm only saying we'd have to implement it, where "we" can be someone else ;) 18:48:10 not royal We but commoner 'we' 18:48:26 or is it the other way around ? 18:48:35 there's a saying in french about "we" typically excluding the person who speaks :p 18:48:47 lol, I like that :D 18:48:53 I'm running a test install on https://raw.githubusercontent.com/ansible-community/ansible-build-data/main/5/galaxy-requirements.yaml just out of curiosity 18:48:55 hahah 18:49:03 French has such great idioms 18:49:05 so "we made a mistake" means "someone else screwed up, not me!" 18:49:19 we will take responsibliity 18:49:26 lol 18:49:32 "we care" 😆 18:49:38 I also like the passive form, "a mistake has been made" 18:50:10 I looked it up and I lied, it's more complicated than I remember (but french is also full of complicated grammar) https://vlf.clg.qc.ca/index.php/2017/01/23/le-pronom-on-exclut-il-la-personne-qui-parle/ 18:50:31 meanwhile, 150s for "ansible-galaxy collection install -r galaxy-requirements.yaml" 18:50:41 I would say that around half is spent doing dependency resolution 18:51:07 he, tha tis with simple deps ... make a complicated chain and you can be up to 90% 18:51:23 specially if any recursivity is involved 18:51:46 in comparison, looking at the 5.5.0 build, downloading the collections took ~73s 18:51:59 which seems like it just takes the dependency resolution timing out of the equation 18:53:14 we kind of veered slightly off topic, should we take some time to discuss collection removal ? 18:53:37 I wonder how much time of the dependency resolution is spent on fetching the required metadata from galaxy 18:54:05 since we only have 6 minutes left, I don't think it makes much sense to switch to that topic now 18:54:07 felixfontein: I don't know, maybe I can tell if I add a bit more verbosity in there 18:54:15 let's do an open floor instead. also feel free to comment on the WIP PR :) 18:54:27 #topic open floor 18:55:12 --verbose doesn't seem to add much output :/ 18:55:58 you probably have to add some print() statements :) 18:56:11 :) 18:56:32 ¯\_(ツ)_/¯ 18:57:22 hmm, but this one finished in 100s instead of 150s -- I guess there's some caching involved 18:57:44 yeah, ansible-galaxy does some caching 18:57:52 because galaxy is so slow ;) 18:58:09 ~/.ansible/galaxy_cache/ 18:59:58 `community.google` went from 29,433 to 30,599 Downloads over the past week 19:00:47 that's a lot more than I thought 19:00:56 though I wonder how many of these were CI runs in antsibull... 19:01:27 The cache lasts about a day as well 19:01:41 Can we disable that somehow (remove it from the collection list)? 19:02:22 I can ask the Galaxy Team if we can get any details of the downloads, not sure what we log 19:02:40 there were 35 CI runs in the antsibull repo since then, each downloads it twice (since two versions of Ansible are built), so 70 downloads come from there 19:03:17 so 1096 other downloads 19:03:29 there were 6 CI runs in ansible-build-data, so 6 downloads from there 19:04:14 it looks like there were a lot more downloads this week than in a random previous week 19:04:23 maybe we sparked some interest in it ;) 19:04:44 anyway, time's over! 19:04:47 #endmeeting