18:04:45 #startmeeting community_working_group_meeting 18:04:45 Meeting started Wed Jul 1 18:04:45 2020 UTC. 18:04:45 This meeting is logged and archived in a public location. 18:04:45 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:04:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:04:45 The meeting name has been set to 'community_working_group_meeting' 18:04:58 * abadger1999 multitasks in 18:05:00 #info agenda https://github.com/ansible/community/issues/539 18:05:34 the actions from last week look funny 18:05:38 like something got missing 18:06:16 someone forgot some #action commands? 18:06:27 #chair cyberpear abadger1999 18:06:27 Current chairs: abadger1999 cyberpear felixfontein 18:06:35 cyberpear: the text seems to be cut off 18:06:39 I'll investigate later 18:07:14 I *think* the next option question (we can answer) is https://github.com/ansible/community/issues/539#issuecomment-643453336 18:07:20 by abadger1999 18:07:37 #info https://github.com/ansible/community/issues/539#issuecomment-643453336 https://github.com/ansible-community/antsibull/issues/94#issuecomment-643451914 18:07:57 #topic What version of ansible-base should ansible depend on? (https://github.com/ansible-community/antsibull/issues/94#issuecomment-643451914) 18:07:59 o/ 18:08:04 #chair acozine 18:08:04 Current chairs: abadger1999 acozine cyberpear felixfontein 18:08:09 I wouldn't lock it to a minimum version unless it's known to be broken without that minimum "patch" version 18:08:42 that way, I can use the latest "ansible" by doing `virtualenv --system-site-packages ...` and only pull down the extra deps needed 18:08:58 but then ansible-base could have bugs that that would be fixed, but aren't because ansible-base wasn't upgraded 18:09:17 so the changelog would be incorrect, since the changes mentioned for ansible-base might not be there 18:10:31 I'd assume that the methods that install "ansible" would also by default pull the latest version of "ansbile-base", but I guess I could be wrong... 18:10:46 Yeah, including the changelog from answible-base inclines me towards advancing the minimum version 18:11:06 I'm not familiar enough with pip... if you do `pip install --upgrade ansible`, ansible-base should also get updated 18:11:35 I'd need to test 18:11:37 but I don't know what happens if you do `pip install ansible==2.10.1` - will it upgrade ansible-base if the currently installed version (from ansible==2.10.0) is "new enough" for 2.10.1? 18:11:52 @felixfontein: except it has a bug that breaks things horribly 18:12:11 webknjaz: but that's when there's ansible 2.9 around, I'm talking about upgrading 2.10.x to 2.10.y :) 18:12:16 I normally do `pip install 'ansible < 2.10' to get 2.9 18:12:17 (or is there another one?) 18:12:36 * samccann sneaks in late 18:12:37 no, that's the one 18:12:45 same for any other version, I specify "less than" the next "major version" 18:12:57 webknjaz: ok. yep, it's horrible, but I think it's unrelated to the current question 18:13:39 cyberpear: for 2.10, that would mean that ansible-base would never get upgraded (after being installed the first time) -- until you start installing ansible 2.11.0 18:13:56 true 18:14:23 does pip have a concept of "recommended" deps vs "required" deps? 18:14:31 no 18:14:35 cyberpear: unfortunately not 18:15:20 I've definitely had to do `--ignore-deps` (whatever it's called) when trying to install an older version of ansible by pip before, but I don't remember the exact details 18:15:39 `--no-deps`? 18:15:45 maybe that's what it was 18:15:55 `--no-deps` 18:16:10 that makes it ignore dependencies 18:16:25 anyway, my preference is to not pin the "patch" version of ansible, but if everyone else disagrees, it's not the end of the world 18:16:42 Define "pin" 18:16:44 ==? 18:16:49 yeah, not pi 18:16:53 but "minimum" 18:16:58 cyberpear: I'm afraid that people will stick with an outdated version of ansible-base if we don't pin the "minor" version (which is what you mean by "patch" version ;) ) 18:16:59 Normally for libs it's `>=` 18:17:25 but then ACD could bump that minimum version occasionally 18:17:26 webknjaz: as new releases of ansible are released, should the minimum version of ansible-base that it requires be advanced as well? 18:17:51 long version: https://github.com/ansible-community/antsibull/issues/94#issuecomment-643451914 18:17:52 (where we're talking ansible-2.10.0 ansible-2.10.1 ansible-2.10.2, and other minor releases) 18:18:05 Hi 18:18:08 following a post by webknjaz :) 18:18:18 my preference is to only bump the PyPI metadata about minimum version when there's actually a technical reason to do so, not to "ensure folks stay up to date" 18:18:18 #chair webknjaz gundalow 18:18:18 Current chairs: abadger1999 acozine cyberpear felixfontein gundalow webknjaz 18:18:25 @abadger1999: I guess that would depend on whether collections in ACD require new features from base 18:18:43 I assume that `ansible --version` will tell the version of ansible-base, as well as ACD? 18:18:44 webknjaz: base shouldn't get new features, only bugfixes 18:19:10 yes, IIUC, ansible-base policy matches old ansible/ansible policy of bugfixes only 18:19:10 cyberpear: the `ansible` executable is part of ansible-base, it doesn't know of ansible (as in ACD) 18:19:15 I mean, there's minor and major bumps 18:20:03 So... to me there's various things going on... I'd say... (1) there shouldn't be new features that aare required. (2) There may be bugfixes that are required (3) The changelog and other documentation will be updated to the newer ansible-base so it feels wrong that what the user gets installed won't match with the changelog. 18:20:16 I can say for example that the network collections require a specific min version of 2.9 to work. I worry something like that could happen in the future as well 18:20:32 does the changelog get "instaled"? 18:20:37 or is it web-only? 18:20:43 (and does this happen today, too?) 18:20:50 cyberpear: ansible --version will tell the version of ansible-base and (at the moment) won't tell the version of the ansible package. 18:21:23 @cyberpear: docs are viewable via `ansible-doc`, so they should probably be updated if changed in base 18:21:25 cyberpear: felixfontein and I (mostly felixfontein ) are working to get the changelog into the ansible tarball. 18:21:48 right now the changelog and porting guide build is separate of the tarball build, we have to integrate it at some point 18:22:32 Also, if the dependency is `>=2.10`, at the ACD's CI must test against the minimal thing that would be `==2.10` and not only the latest matching. 18:22:55 webknjaz: is that how deps are handled today in CI? 18:23:19 most collections test against the latest 2.10, latest devel, and maybe latest 2.9, but they won't test against 2.10.0 (except when it's still latest) 18:24:47 since ansible is distinct from ansible-base, would it make sense to have different changelogs for each, or is "ansible" supposed to aggregate them all and make folks unaware of ansible-base? 18:25:06 #info Pro: changelog included in the latest ansible-2.10.x will be for the latest ansible-base 18:25:41 cyberpear: that's how changelog (and in the second file at the bottom, porting guide) currently could look like: https://gist.github.com/felixfontein/7d5efcc70c8a25c218d9e8082f5ee92f 18:25:49 #info Pro: most collections will test against the latest ansible-base-2.10.x 18:26:02 cyberpear: for every version it lists all changes for ansible-base, and for included collections 18:26:27 #info Con: Prevents users from choosing to use the ansible packaged collections with an older version of ansible-base. 18:28:02 users can still choose by installing ansible with --no-deps 18:28:08 (since ansible-base is the only dependency) 18:28:32 It'll be a problem with `pip>=21` 18:28:39 potentially 18:28:40 webknjaz: why? 18:28:42 webknjaz: can you explain further? 18:29:00 Because the new resolver will enforce correct envs 18:29:12 AFAIK 18:29:25 not sure what will happen to `--no-deps` tho 18:29:31 link? do you mean that `--no-deps` does away? 18:29:37 what's a "correct env"? 18:30:08 the current "old" resolver has a lot of bugs and may not resolve all the transitive dependencies correctly 18:30:18 so it's been rewritten 18:30:34 and available via `--unstable-feature=resolver` CLI arg 18:30:41 probably that deps for all packages are all satisfied (although from what upstream has said, it doesn't seem like the environment will be correct... at most that the transaction will be correct) 18:31:05 that one will try to resolve all the tree properly 18:31:16 * acozine has to handle a family thing, BIAB 18:31:17 but even now there's a command for checking the env 18:31:21 `pip check` 18:31:31 if there's conflicts, it fails 18:31:43 interesting 18:31:52 AFAIK they want to enable this check by default 18:32:39 I suppose most folks will get it from apt/yum/dnf though, which handle deps in their own way, but good to know about the pip changes 18:32:58 Maybe it'll be possible to install conflicting stuff with `--no-deps` but most likely it'll become harder to manage such envs 18:33:47 @cyberpear: well, among Pythonistas most folks will get it from Pip and never OS package managers. I personally never install it on the OS level 18:34:23 Do we have new things to say here or should we just vote? 18:34:37 (I don't have any data, but I'd assume most folks using ansible aren't pythonistas) 18:34:42 do we have stats how often ansible is installed via pip vs. how often it is installed via a package manager? (not sure whether such stats are possible after all) 18:35:20 No... I believe there were surveys in the past but they'll be out of date and I don't know the possible biases. 18:35:20 abadger1999: I think there's not much new. but I'm not sure we're enough that a vote actually says something 18:35:30 (I believe it was like 30% pip install at that time) 18:35:52 my guess is that RH would have some stats as to which packages their customers have installed, but other distros won't have that data... and ansible itself doesn't "phone home" 18:36:09 cyberpear: I really like that it doesn't phone home! 18:36:12 yes 18:36:17 (I hate software that just does that) 18:36:33 Yeah.... But my guess is RHT customers will heavily skew towards installing from system packages :-) 18:36:41 and instrumenting ansible-galaxy commands to include such data would be biased because folks using distro ansible packages might also be using distro-packaged content 18:37:20 I never install from ansible-galaxy, usually pointing to the relevant git repo when I need something external 18:37:35 I've got nothing new on-topic 18:38:07 okay... well, I'll need a decision here... Do we want to take a vote? Just have me make the decision on this? Establish some other rule about what gets us to the decision? 18:39:04 probably just vote, or if too few people... 18:39:05 let's vote then 18:39:07 #chair 18:39:07 Current chairs: abadger1999 acozine cyberpear felixfontein gundalow webknjaz 18:39:19 acozine isn't around, so there are 5 of us 18:39:29 I hope gundalow knows what we are talking about :) 18:39:30 * samccann waves 18:39:45 felixfontein: nop, sorry in another meeting 18:39:52 :( 18:40:10 though I trust others here :) 18:40:24 #chair samccann 18:40:24 Current chairs: abadger1999 acozine cyberpear felixfontein gundalow samccann webknjaz 18:40:29 ok, then let's try :) 18:41:12 Proposed: the minimum version dep of ansible-base in the ansible package will advance with new ansible releases. 18:41:13 POLL: should the ansible 2.10.x pip package depend on ansible-base >= 2.10.0, or on ansible-base >= 2.10.y where y is the latest release that was around when ansible 2.10.x was built? 18:41:36 +1 2.10.y 18:41:37 POLL: should the ansible 2.10.x pip package (a) depend on ansible-base >= 2.10.0, or (b) on ansible-base >= 2.10.y where y is the latest release that was around when ansible 2.10.x was built? 18:41:50 this way we can use (a) and (b) instead of random other notation ;) 18:41:52 (b) +1 18:41:55 b 18:41:57 a 18:41:59 (b) +1 18:42:20 b 18:43:21 hmm, looks like this is pretty clear 18:43:31 since acozine and gundalow aren't around: 18:44:04 #info ansible 2.10.x should depend on ansible-base >= 2.10.y with latest y that was around when ansible 2.10.x was built (4 yes, 1 no) 18:44:53 ok 18:45:05 Cool. 18:45:09 I'll make it so. 18:45:18 #topic Should symlinks in c.g and c.n be removed for 1.0.0, or for later? https://github.com/ansible/community/issues/539#issuecomment-646027549 18:45:27 abadger1999: I thought it already is :) 18:45:53 I'd keep them around for as long as 2.9 is supported, and perhaps a little longer 18:45:53 I think so but I want to double check after decisions are finalized ;-) 18:45:57 background: since there isn't really flatmapping, there are symlinks from plugins/modules/shortname.py to plugins/modules/dir1/dir2/shortname.py 18:46:21 they can be replaced by meta/runtime.yml redirect entries, but these are only understood by 2.10 or newer 18:46:50 I've written a tool which can easily convert between the two, so it's easy to switch if we want 18:46:55 (in both ways) 18:47:01 we hadn't been planning on the collections supporting 2.9 except by happenstance. But my major concern was making sure the runtime.yml support actually worked which the 0.3.0 branch achieves. 18:47:08 so essentially this question boils down to: how long to we want to support 2.9? 18:47:36 there's currently a 0.3.0-experimental.meta.redirects release of community.general which has no symlinks, but only runtime.yml entries 18:47:53 there is no final 0.3.0 release planned, this is only for trying this out 18:48:00 (it's also not part of the master branch) 18:48:25 are collections in 2.9 still considered "tech preview"? 18:48:50 cyberpear: I think so. but with 2.9.10 or newer, most things in the current collections should work fine 18:49:00 I can't remember if that was 2.9 or 2.8.... /me looks for any documentation on that. 18:49:12 2.8 was the first release w/ collections 18:49:20 and there, I think it was announced as "tech preview" 18:49:22 IIRC 18:49:43 They are supported in 2.9: https://www.ansible.com/blog/getting-started-with-ansible-collections 18:50:01 Ansible Content Collections were first introduced as tech preview in Ansible Engine 2.8 and are now fully supported in Ansible Engine 2.9 and are an integral part of Red Hat Ansible Automation Platform. 18:50:23 since it's "fully supported", I'd say we should maintain the symlinks 18:50:54 the current ones are only "fully supported" in 2.9.10+ 18:51:04 (thanks to some feature backports) 18:51:24 yeah, I think it's safe to tell folks to use the latest patch version to get all the fixes 18:51:25 (or at least partial feature backports) 18:51:45 (I assume no one wants to backport runtime.yml support to 2.9) 18:51:52 I don't think so 18:52:02 I'm okay leaving the symlinks for now (since we have the 0.3.0 branch) but would like to defer the question of how long we're supporting 2.9. 18:52:13 the chance of randomly breaking things is too high. and it would be a LOT of effort 18:52:39 I would prefer to support 2.9 at least for the 1.x.y line; for 2.x.y we could discuss this again 18:52:50 I think there's internal discussion of how long 2.9 will be supported, too... so I don't want community contributors to sign up to support 2.9 when they don't know how many years that will be for. 18:52:51 (i.e. in 6 months) 18:53:44 also we're not Supporing 2.9, we only don't actively not support it ;) 18:53:47 that could make sense too. 18:54:06 lol now there's a statement! 18:54:06 I'd like to enable some CI with 2.9 eventually when we want to not un-support it, so we at least have some basic coverage 18:55:03 (for those interested, I already have a PR for that: https://github.com/ansible-collections/community.general/pull/296) 18:55:10 (it's green up to a hanging test, but that's not related to 2.9) 18:55:31 Cool. 18:55:56 so let's vote, so we have this in writing ;) 18:56:13 Are we ready for a poll? 18:56:17 POLL: should we try to support 2.9 as good as we can (without investing too much time) for at least the 1.x.y releases? 18:56:27 hmm, good question 18:56:31 +1 18:56:39 +1 18:56:41 does anyone want more discussion? (please don't write +1 or -1 for that :D ) 18:56:49 +1 (for the poll) 18:56:50 felixfontein: Sorry, that was, I think as you do, i just don't type as fast ;-) 18:57:10 abadger1999: lol ok :) 18:57:24 if nobody claims that they want more discussion, we can just complete the poll 18:57:44 +1 in answer to the poll 18:58:08 webknjaz: gundalow: any opinion on this? 18:58:36 the main disadvantage of supporting 2.9 is that CI will get even slower ;) 18:58:39 +1 18:59:01 (and that three ignore.txt files need to get updated) 18:59:36 ok 18:59:58 #info community.network and community.general will (try to) support ansible 2.9 at least for the 1.x.y releases 19:00:28 (I hope nobody minds that I mention both large collections here) 19:00:57 ok 19:01:01 I guess we're mostly done for today. 19:01:31 one short announcement: in case you don't know, in all ansible-managed collections (i.e. in particular the ones in github.com/ansible-collections) the `master` branch will be renamed to `main` 19:02:24 I'll try to do that for community.crypto tomorrow, and we'll do that for community.general on monday, and community.network maybe already on friday (if gundalow gives a green light) 19:03:14 Nice :-) 19:03:20 \o/ 19:03:39 for more information see https://github.com/ansible-collections/overview/issues/87 and https://github.com/ansible/community/wiki/Changing-the-git-default-branch-to-main 19:04:00 and https://github.com/ansible-collections/overview/issues/83 for the initial discussion 19:04:29 I'll add announcement issues to the collection repos soon (and CC everyone who forked the repo) 19:04:54 community.general is close to 200 forks, the others have a lot less fortunately 19:05:46 ok 19:06:01 should we continue with the open floor? (without a trapdoor? :) ) 19:06:14 heh 19:06:47 #topic open floor 19:07:54 If we make any statements about 2.9 support then I'm happy to cover CI costs. (If we aren't testing it, it IS broken) 19:08:47 oh, I skipped one topic: https://github.com/ansible/community/issues/539#issuecomment-643764618 - use semver for ansible versions. let's discuss that next week or when there are no more pressing other issues :) 19:08:51 gundalow: that would be awesome! 19:09:40 Oh. 19:10:09 looks like we need more agenda items soon ;) right now we only have that one and two items by cyberpear left 19:10:16 Saturday is a US holiday. Many US people (including US RHTers) haveFriday off. 19:10:37 ah 19:10:43 that is a good thing to know 19:10:59 just an FYI for non-US people if they wonder why the US people disappeared from Friday through Monday this week ;-) 19:11:06 if we change branches on Friday for c.n, someone would need to adjust the default branch in GitHub, because I don't have permissions for that 19:11:17 gundalow: are you around on Friday? 19:11:25 (since you're not US-based :) ) 19:11:55 disappeared?, will disappear?, will have disappeared? ( What is that.... the future pluperfect?) 19:12:00 also we need to figure out why the nightly community.internal_test_tools build is still not working, as this will probably affect the other repos as well 19:12:32 `will have disappeared' sounds right to me 19:12:40 felixfontein: yup, I'm here on Friday 19:12:44 but that might also come from my mother tongue's influence :) 19:12:55 :-) 19:13:00 gundalow: awesome! should we change branch for community.network then? 19:13:01 It sounds the best to me too 19:13:35 i'd go with will have had disappeared... just to be sure ...nobody understands it :-) 19:13:48 lol :) 19:13:49 felixfontein: community.internal_test_tools should work from the next run, I've merged the `master|main` CI scheduling change 19:14:10 gundalow: ah, so you didn't merge it yesterday? that of course explains why it didn't work today ;) 19:14:17 (I was somehow assuming you already merged it) 19:14:31 cool! 19:14:36 so I guess it's time for: 19:14:37 #endmeeting