19:00:15 #startmeeting Ansible Community Meeting 19:00:15 Meeting started Wed Nov 18 19:00:15 2020 UTC. 19:00:15 This meeting is logged and archived in a public location. 19:00:15 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:15 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:15 The meeting name has been set to 'ansible_community_meeting' 19:00:20 hi all! 19:00:27 👋 19:00:30 \o 19:00:34 o/ 19:00:34 * gundalow waves 19:00:40 hi 19:00:40 Greetings :-) 19:00:40 #chair briantist samccann jillr gundalow 19:00:40 Current chairs: briantist felixfontein gundalow jillr samccann 19:00:44 #chair dericcrago abadger1999 19:00:44 Current chairs: abadger1999 briantist dericcrago felixfontein gundalow jillr samccann 19:00:54 \o 19:01:01 #chair dmsimard 19:01:01 Current chairs: abadger1999 briantist dericcrago dmsimard felixfontein gundalow jillr samccann 19:01:02 o/ 19:01:04 andersson007_: acozine: geerlingguy: resmo: gwmngilfen: cyberpear: 19:01:09 #chair cybette 19:01:09 Current chairs: abadger1999 briantist cybette dericcrago dmsimard felixfontein gundalow jillr samccann 19:01:24 o/ 19:01:25 ah right andersson007_ isn't around today 19:01:29 #chair acozine 19:01:29 Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein gundalow jillr samccann 19:01:53 #topic agenda: https://github.com/ansible/community/issues/539 (the last few comments) 19:01:59 #chair geerlingguy 19:01:59 Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr samccann 19:02:14 welcome everyone! 19:02:18 #halp 19:02:21 hi 19:02:26 #chair cyberpear 19:02:26 Current chairs: abadger1999 acozine briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr samccann 19:02:27 aww, I wanted to see what that does 19:02:29 hi 19:02:34 #chair aminvakil 19:02:34 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr samccann 19:02:56 #help 19:03:04 geerlingguy: send a message to the Fedora Community operations Channel 19:03:04 anyone else who wants to become furniture, just say hi :) 19:03:08 geerlingguy : no such thing I guess 19:03:24 * gwmngilfen is doing bedtime, but can dip in if stats things come up 19:03:27 #topic announcements 19:03:52 #info community.docker, community.postgresql and community.routeros 1.0.0 were released this week and will be included in the next Ansible 2.10 release 19:04:07 (they contain content moved out from community.general and community.network) 19:04:14 Yaaay 19:04:34 #info The Bullhorn 14 has been published today: https://mailchi.mp/redhat/the-bullhorn-14 19:04:34 🎉 19:04:37 #info Next two Ansible PR days are Tue 1st Dec and Thu 17th December. Calendar invite is in https://github.com/ansible/community/issues/407 Hope to see you there 19:04:42 #chair briantist 19:04:42 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr samccann 19:05:01 that's a lotta bull 19:05:35 heh 19:05:43 :D 19:05:48 geerlingguy: we're bullish? 19:05:48 #info Ansible-2.10.4 will be released on Tues, 1st Dec (or possibly 2nd December according to timezones ;-) 19:05:55 it's... incredibull 19:05:56 #info please review https://github.com/ansible-collections/community.general/pull/1303 and https://github.com/ansible-collections/community.general/pull/1304, in particular the changelog fragments, since we will replicate them a lot 19:05:56 https://github.com/ansible-collections/community.general/pull/1303 | open, created 2020-11-14T19:43:15Z by felixfontein: [WIP] Add information on docker module migration [WIP,affects_2.10,docs,has_issue,needs_triage,owner_pr] 19:06:09 Adora-bull 19:06:10 geerlingguy: as long as it's not a bull's hit. 19:06:11 Hello o/ 19:06:16 #chair lmodemal 19:06:16 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal samccann 19:06:20 #chair gwmngilfen 19:06:20 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen jillr lmodemal samccann 19:06:37 lol my watch is going insane, it vibrates at every mention 19:07:12 :) 19:07:20 does anyone else have an announcement to make? 19:07:37 I am eating a turkey sandwich 19:07:47 #info No IRC Meeting next week (25th Nov) as lots of people are off that week 19:07:48 hmmm ansible/devel is ansible-core now 19:08:01 no public announcement material yet 19:08:14 #info ansible/ansible is now `ansible-core` (previously ansible-base) https://github.com/ansible/ansible/pull/72594 19:08:16 https://github.com/ansible/ansible/pull/72594 | closed, created 2020-11-12T00:53:41Z by relrod: Rename to ansible-core [affects_2.11,bug,shipit,support:community,support:core,test] 19:08:19 dmsimard: thanks for the reminder 19:11:00 abadger1999 suggested to do some quick votes first on the release schedule and semantic versioning for the ansible package, and then discuss inclusion of new collections in 2.11 since that's getting more urgent 19:11:18 +1 19:11:47 #topic Semantic versioning of the ansible package 19:11:52 I'm fine with that, as long as nobody objects to dellemc.openmanage to be included in ansible 2.10, assuming they run at least sanity checks in public CI (I hope they have more checks running somewhere, but not visible publicly) 19:12:09 #info related proposal: https://github.com/ansible/proposals/issues/179 19:12:42 semantic versioning would be for the ansible package, not for ansible-base/ansible-core 19:12:51 right? 19:12:58 (Let's have a quick vote on dellemv.openmanage inclusion too, after the two release votes) 19:12:58 +1 19:13:04 Correct 19:13:25 ansible-core is talking about semantic versioning but even if they do that, it won't be soon. 19:13:27 does anyone wants to discuss this, or needs more information etc., or should we just vote? 19:14:18 I'm catching up rather quickly 19:14:18 vote? 19:14:19 does anyone see a downside/problem with having Ansible use semantic versioning? 19:14:39 does this mean the next release of the `ansible` package on PyPI would be `3.0`? 19:14:43 samccann: it's different to what we do today, though I known generally speaking, people have asked for it 19:14:46 I have the proposal to vote on once we're done with discussion 19:15:07 acozine: Yes, the next major release (In February) would be 3.0.0. 19:15:16 gundalow: yeah I'm in favor of it for sure. Just wanted to know if anyone has identified potential gotchas (big gotchas) 19:15:21 so no ansible 2.11 19:15:27 The -evrey-three-weeks releases of that will look like 3.1.0, 3.2.0, etc. 19:15:29 Yep. 19:15:38 Main gotcha is probably that we'll be on version like 35 by 2023 19:15:42 Instead of 2.11.0, we'll release 3.0.0 19:15:46 But Firefox is up to what? 82 now? 19:15:46 and if we have to do a re-release like recently, we'll get a patch release 19:16:04 would it be confusing to have mismatched version numbers between ansible-core and ansible ? 19:16:10 thanks for the details abadger1999 felixfontein 19:16:14 that's already happening dsim 19:16:18 dmsimard: ^ 19:16:19 I don't like it. I think major version bumps should indicate major breakage 19:16:20 dmsimard: that's almost a feature 19:16:20 dmsimard: We are already there ;) 19:16:25 What's the downstream impact? aka will this cause grief from The Powers That Be on the RH side or did we already talk to them about this? 19:16:46 dmsimard: it's already confusing, since there are two different 2.10.x streams 19:17:12 * ikhan_ waves 19:17:17 #chair ikhan_ 19:17:17 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr lmodemal samccann 19:17:18 dmsimard: We're going to have that anyway (if we stayed with 2.11, we'd have ansible-base-2.10 and ansible-2.11, followed by ansible-core-2.11 and ansible-2.12) 19:17:24 no matter what version number we give to the next release, there will be a mismatch between ansible-core and ansible 19:17:29 So diverging more quickly is probably less confusing overall 19:17:37 understood 19:17:56 By the end of 2021 `ansible` would be on 5.0.0, while `ansible-core` would likely be 2.11 19:18:05 These are all good questions to ask :) 19:18:10 abadger1999: I agree that using 3.0 next would be easier to explain . .. well, not explain, but make it easier to see at a glance which thing we're talking about 19:18:10 How often would a major version be released (sorry if this piece of info is already somewhere)? 19:18:19 samccann: We have reached out to thaumos and robyn and they both approved. 19:18:23 cyperbear: can you elaborate? To me, Ansible the package is all about the collections included.. .which are using semver. So making it also use semver seems logical to me. 19:18:34 tadeboro: for `ansible` major version bump every ~3-4 months 19:18:47 #chair tadeboro 19:18:47 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr lmodemal samccann tadeboro 19:18:49 I still think we should tie the version of the community distribution to the core package 19:18:50 I actually kinda like having different ansible/ansible-core versions, to clarify that one is a meta packaging of multiple components with different dev cycles 19:19:13 as that will allow `ansible` to pull in the new major versions of the collections (which by definition would have breaking changes) 19:19:29 cyberpear: many users asked about whether 2.10 should have been called 3.0 to begin with -- I'm personally torn on that but recognize that the shift to collections is likely significant enough to warrant calling it as such 19:19:36 jillr: Corrext. the ansible package is depends on some major version of the ansible-core package + includes specific versions of certain colletcions. 19:20:01 I've already had folks in issues trying to test with different ansible-base versions but not different collection versions because it's not obvious that ansible-base has no effect on the collection rev to them 19:20:02 So 3-4 versions a year is not that bad. And how long do we intend to support backward-compatibility? 2 years? 19:20:23 I still wish 2.10 were 3.0 19:20:28 cyperpear: I struggle to see how we can keep the Ansible version tied to ansible-core version and still bring in new collections and breaking changes. 19:20:29 abadger1999: right but I feel like it helps community that these things are not 1:1 equivalents 19:20:32 tadeboro: The current plan is that only the latest release of ansible is supported. 19:20:36 s/community/communicate 19:20:37 It didn't break my playbooks technically, but it's a totally new Ansible (IMO) 19:20:37 geerlingguy, +1 19:20:42 tadeboro: depends on the collections 19:21:14 tadeboro: I have a feeling we're going to need to re-discuss and re-vote on that when ansible-3.0 comes out or when ansible-4.0 comes out (4.0 will rebase onto ansible-core-2.11 so it will be a more major release) 19:22:03 Potentially breaking playbooks three times a year does not sound good. 19:22:40 I think two major versions a year are enough potential breakage 19:22:44 for that case you would stick with ansible-core instead 19:23:08 I know c.g and other community collections will make sure this does not happen. But I have less trust in certified collections (as weird as this sounds). 19:23:12 ansible-core (pinned) + collections you care about (pinned) 19:23:15 what bcoca said — I know I hope to start moving more of my work to `ansible-core` as time goes on 19:23:33 (version pinned) 19:23:34 that gives 'ansible the giant package' more room to be experimental 19:23:43 Oh, or are you talking about the deprecation cycles? If so, what felixfontein is saying is the answer... individual collections control their own deprecation cycles. The ansible package will have new major releases with potential backwards incompatible changes from the collections 3-4 times a year. 19:23:52 only issue is people have relied on 'ansilbe' package being 'the stable' one, but that is now reve4rsed 19:24:23 bcoca: ansible wasn't really stable, every new 2.x.0 release had breaking changes 19:24:37 We just wrote a modern intro to Ansible that instructs users to handpick the content they use, but there is a lot of existing content and no one to migrate it. 19:25:35 hello folks 19:25:46 most existing content should just work (assuming you installed the right collections) 19:25:59 so from the sounds of it, Ansible always had some level of breaking changes... and users had to adapt to each upgrade... and we are saying the same will happen with Ansible going forward, yes? 19:26:10 Okay.... I think we're getting into a different topic. 19:26:15 except we'd be back to a 3-4 times a year cadence 19:26:17 samccann: yes 19:26:21 hi jtanner! 19:26:23 #chair jtanner 19:26:23 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro 19:26:51 I think they're less urgent than the three things I would like to get to today. 19:26:59 samccann: it sounds to me like yes, but by putting those under major version numbers it should be more obvious that it would happen? and we give folks a way to not break, by sticking with ansible-core revs that move slower 19:27:33 agreed jillr 19:27:39 sorry abadger1999 19:27:46 tadeboro: Can I put: ansible package release cadence and deprecation cycle onto the agenda (probably for discussion in December since I think net-new collection policy is going to take up the next few meetings)? 19:28:24 abadger1999: Sure. It was not my intention to block the meeting at all. 19:28:28 Cool. 19:28:35 +1, I think it's a good topic to discuss 19:28:37 ok. vote, or postpone this topic? 19:28:42 If we're ready, here's my proposal to vote on: 19:28:43 Vote. 19:28:44 VOTE: The next major release of ansible will be 3.0.0; Ansible releases will follow semantic versioning going forward from there. 19:28:47 s/discuss/discuss later/ 19:28:52 +1 19:28:53 +1 19:28:55 +1 19:28:55 +1 19:28:56 +1 19:28:56 +1 19:28:57 +1 19:28:59 +1 19:29:03 +1 19:29:04 +1 19:29:07 #chair 19:29:07 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro 19:29:20 +1 19:29:20 +1 19:29:31 -1 19:29:51 i rather not to vote on this 19:29:53 -1 if "ansible" is refering to the thing formerly known as ACD 19:30:12 jtanner: correct 19:30:27 jtanner: could you explain why you are `-1`? 19:30:45 I'm curious - cyberpear you said you'd like to tie `ansible` releases to `ansible-core` releases 19:30:54 jtanner: what would you prefer for versioning? 19:31:32 because aside from the branding, the language features are what i associate to the version of "ansible" and content/collections/etc aren't additions to the language imho 19:32:04 #agreed The next major release of ansible will be 3.0.0; Ansible releases will follow semantic versioning going forward from there (12 x +1, 1 x 0, 2 x -1) 19:32:41 yes, tying them together would be my preference. ansible being a meta package... also agree w jtanner 19:32:42 jtanner - I would love Ansible the package to have a different name... it would sure help with all of this. 19:32:50 @gundalow so what will be the feature different between 2.10 and 3.0 (other than new collections content)? 19:33:10 if ansible-core were developed hand-in-hand with all the collections then I could agree (but would still like core to use semver heh)... but it's not 19:33:17 ikhan_: none. but there are breaking changes for modules and plugins 19:33:20 jtanner: I would consider the union of all included collections' APIs as something that must follow the rules of semver since this is what playbooks use. 19:33:40 I agree with tadeboro 19:33:42 jtanner: I do agree with that idea, however, at current, the language is defined by the ansible-core package so I think that the ansible-core package probably needs to reflect the language version instead of the ansible package. 19:34:06 maybe ... i did say "imho" 19:34:07 jtanner: You break my playbook once, I will fix it. Do it twice in a row, I am looking for something more stable ... 19:34:15 ikhan_: new collections ocntent which can have backwards incompatibilities. 19:34:18 roles/playbooks can break. it doesn't matter whether it's a language feature which changes, or one of the modules/plugins they use 19:34:23 tadeboro: heh, /me nervously looks at Ansible 2.3, 2.4, and 2.5 19:34:28 @felixfontein so because we are carrying breaking changes in collections technically the whole package is not backward compatible - is that true? 19:34:34 tic-tac-toe on those three releases breaking things 19:34:48 ikhan_: correct 19:34:50 ikhan_: yes 19:35:09 Linux kernel version isn't related to Distro version 19:35:13 I think the main concern (at least for me) is the end-user optics. 99% of Ansible users are not writing python modules and things like that, they write playbooks 19:35:35 Go language version is not related to Kubernetes version... etc. 19:35:45 gundalow: the difference is that the kernel is not the interface to the linux distro, whereas core is the interface here 19:35:46 gundalow: agreed... but then we also have - linux distros have different names. They aren't called just Linux 19:35:47 usually if you stick to a smaller set of collections, new major releases will be needed way less often. but having a huge amount of different collections that release independently, we need regular major releases 19:35:52 so we do meet the criteria for reving major version 19:36:05 I'm slightly less concerned with the name of the meta package and more interested that it has its own versioning/cadence based on its contents 19:36:15 ikhan_: yes, probably frequently (2-3x per year) 19:36:21 jillr++ 19:36:35 so we'd be on "Ansible 7" or so in 2022 19:36:55 though we should pick a name and stick with it for a good long while, and not keep changing it 19:37:48 geerlingguy: otherwise we'd be at 2.17, which would have as many breaking releases as 7.0.0 19:38:10 Yep, except everyone else is like "wow Ansible is so outdated, they still are on version 2 after 5 years" 19:38:11 if every collection/ansible-core(base) is on their own rev number and Ansible package is at their own rev then binding ansible package to ansible-core does not make any sense 19:38:41 ikhan_: it is not bound to the ansible-core version anyway 19:39:04 they coincidently have the same version until next february, then they will have different versions 19:39:26 @felixfontein makes sense - it's just the naming makes it confusing 19:39:29 it might be quite obvious, but i can't understand this. is there a reason to release a new minor version every 3 week, which would result in having breaking changes in 3 or 4 months? 19:39:41 ikhan_: Collections release versions as they fit, so there is not bond between any collection version number or ansible(-base,-core) release. 19:39:52 geerlingguy: yes.... that was something that thaumos liked, btw, because it causes less confusion with ansible-core versions. I like it because model for the ansible package is now "Fedora and other Linux distros" and the major version reving in Fedora is actually a very good model for something that's an aggregate. 19:40:04 ikhan_: +1 19:40:39 aminvakil: The new minor version every 3weeks is so that bugfixes can be made to the ansible package. 19:40:45 (on a predictable schedule) 19:41:07 aminvakil: The main "breaker" of compatibility are collections, and we have no control over some of them. 19:41:07 aminvakil: it's essentially the same thing we do right now, except that we use semver 19:41:17 Yeah like Fedora is on what, 34 now? CentOS/RHEL are on 8 19:41:23 it seems to work out 19:41:39 Question: Is there anyone who would like to change their vote? Otherwise we need to move on. 19:41:48 We could just call it "Ansible Community Edition" to clear up the confusion 19:41:55 heh 19:41:58 Ansible CE for short, like `docker-ce` 19:41:59 +1 19:42:01 There's one more "easy" vote ;-) and a humongous discussion yet to get to today ;-) 19:42:11 Though I know you start getting legal, marketing, product, etc. people all in a tizzy with that :D 19:42:44 tadeboro: gotcha 19:42:57 geerlingguy: current docker-ce version is 19.03.13-ce - the first two parts are year and month. says a lot about how alive and kicking it is :) 19:43:03 DING DING DING: Given the above discussion does anyone want to change their vote? 19:43:30 abadger1999: it make sense to me and I am ok with 3.0. the only concern that I have is that it will be very confusing for the consumers of the package to figure out why this change happened. It needs to be clearly articulated and I don't know how that will happen 19:43:37 basing releases on a fixed amount of time sounds more like calver than semver to me 19:43:56 +1 19:44:17 dericcrago: if we ever have a release with no breaking changes in collections, we will only tick up the x.y+1.z 19:44:18 +1 19:44:29 +1 ikhan_ 19:44:55 #topic Release schedule for ansible-3.0.0 19:45:15 ok, new topic :) 19:45:21 I brought this up last meeting. Since then I have gotten sign off from internal people. 19:45:40 #info tentative schedule for 3.0.0: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw 19:45:40 So I'd like to get a vote here to approve it on the community side. 19:45:46 https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw 19:45:53 I guess we only vote on the 3.0.0 part, not on the 4.0.0 part 19:45:53 #info Proposed schedule: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw 19:46:12 Correct. The 4.0.0 part is informational but it's too tentative at this point to vote on. 19:46:43 So... it's basically, do you approve this section of the doc: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw#Proposed-Schedule-for-Ansible-30 19:47:07 Looks good to me 19:47:13 The only change from last week is that I added dates for net-new collections to be added. 19:47:19 2020-12-16: Finalize rules for net-new collections submitted for the ansible release. 19:47:30 2021-01-16: Final day for net-new collections to be **reviewed and approved.** 19:47:52 Hmm... mistake on the latter date 19:48:28 Should be 2021-01-27 Final day for net-new collections to be **reviewed and approved.** 19:48:32 * abadger1999 corrects the document 19:48:49 #info 2020-12-16: Finalize rules for net-new collections submitted for the ansible release. 19:48:59 #info 2021-01-27: Final day for net-new collections to be **reviewed and approved.** 19:49:27 when we say "finalize rules for net-new collections", is there anything to look at yet ? 19:49:37 dmsimard: that will be the next topic of discussion :) 19:49:51 hehe, we're executing these things in parallel, out-of-order execution 19:49:53 resp. after a quick discussion on a specific collection 19:50:00 (though that criteria is probably the most contentious) 19:50:05 VOTE: Approve https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw#Proposed-Schedule-for-Ansible-30 as the release schedule for Ansible-3.0.0 19:50:14 +1 19:50:15 +1 19:50:16 +1 19:50:17 +1 19:50:18 +1 19:50:18 +1 19:50:49 +1 19:50:55 +1 19:51:03 +1 19:51:03 +1 19:51:03 +1 19:51:27 beta and RC seem quite close together, but I guess it's fine for a meta-package 19:52:31 cyberpear: since there is no new ansible-core version, should be fine 19:52:42 cyberpear: the proposed schedule for 4.0.0 has a lot more time 19:52:44 cyberpear: yeah. I included the tentative schedule for the 4.0.0 release because I think the beta/rc/final period for 3.0.0 can be short whereas the beta/rc/final period for 4.0.0 needs to be much longer (more potential blockers because we're rebasing against ansible-core-2.11 in that releae) 19:53:04 Cool, anymore votes for the schedule topic? 19:53:16 +1 (sorry, mind was wandering) 19:53:31 #chair 19:53:31 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro 19:53:48 felix knows the cheat code to ping everyone 19:53:52 +1 19:54:09 #agreed approved https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw#Proposed-Schedule-for-Ansible-30 as the release schedule for Ansible 3.0.0 (13 x +1) 19:54:17 ok 19:54:45 Okay, cool.... Now for the big topic... 19:54:48 #action gundalow to copy https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw#Proposed-Schedule-for-Ansible-30 to reddit 19:55:08 there's a "bigger" topic? 19:55:27 #topic inclusion of dellemc.openmanage (https://github.com/dell/dellemc-openmanage-ansible-modules/tree/collections) in 2.10.x for transfer of some content from c.g (https://github.com/ansible-collections/community.general/pull/948) 19:55:35 jtanner: these were juts the wamups 19:55:38 this is hopefully a quick one :) 19:55:38 Oh, right :-) 19:55:44 that's not the big one yet :p 19:55:45 One more quick vote first 19:55:46 oh, is this the "new content" topic? 19:55:58 Yeah, net-new content will be coming up right after this. 19:56:21 we have several moves of content from c.g/c.n/other collections to new collections and will include them in Aansible 2.10.x, but this one is a bit special since the collection contains much more than the moved content 19:56:48 the content moved is 2 x module_utils, 3 x modules (and tests) 19:57:06 the collection has a lot more content: https://galaxy.ansible.com/dellemc/openmanage 19:57:55 woah 19:58:01 I lack historical context so I'm going to abstain; I also need to step away for a couple minutes 19:58:09 I don't see any CI in their repo? 19:58:10 who/what is the driver for including it before we formalize rules on adding collections ? 19:58:18 how can we guarantee quality? 19:58:30 ^ what I mean by formalizing rules 19:58:47 * geerlingguy do you even test? 19:59:16 I am okay with the increase in content.... My rationale is that if it was moved first and got into 2.10.4, the new content could be added to the collection after that and then the new collection would get into 2.10.5.... Separating the change between the two versions would be an artificial time barrier without any user benefit that I can see. 19:59:21 changelog is also not using antsibull-changelog (fwiw) 19:59:27 No CI at the moment, I raised a PR though GitHub Actions don't seem to be enabled https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 (though in my fork a lot is failing) 19:59:27 https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 | open, created 2020-11-18T12:57:28Z by gundalow: WIP Run ansible-test sanity & units 19:59:29 looks like gundalow has a WIP for CI here here: https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 19:59:30 https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 | open, created 2020-11-18T12:57:28Z by gundalow: WIP Run ansible-test sanity & units 20:00:02 there's a whole lotta red there 20:00:11 If the new collection doesn't follow the checklist, then that is a different issue that I might have a problem with. 20:00:20 geerlingguy: if changelog would be an argument, ansible would shrink noticable :) 20:00:29 true, just putting that out there 20:00:49 the idea being that it would be nice, as we balloon ansible ever-larger, if we were able to maintain at least a minimum set of requirements 20:01:01 Passing `ansible-test sanity` is a requirement to be included in `ansible` 20:01:06 'passes sanity' would be absolute lowest minimum I think 20:01:28 'has integration tests' would also be nice, but maybe not an absolute requirement 20:01:29 right now we have https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst 20:02:05 dmsimard: yeah, it does mention sanity 20:02:23 geerlingguy: I'm also not 100% happy with it, but right now I'm happy about everything we can remove from c.g/c.n, and including it would be a reason to remove some more content fromm c.g 20:02:51 geerlingguy: we will get onto requirements in the next #topic, though yes `sanity` is the bare min, and I'd love to raise the bar a lot hire 20:03:15 I would assume that they have better tests, but not in a public CI. but that's something we'll have to ask for. 20:03:31 felixfontein: if it is not an emergency (which it doesn't seem like it is), I'd wait until we formalize rules on inclusion to ansible 20:03:31 (maybe I'm also too optimistic :) ) 20:03:45 dmsimard: fine for me 20:04:09 do we want a formal vote or table it for a next meeting ? 20:04:10 VOTE: a) add collection now, b) reconsider after we have the rules set up 20:04:19 b 20:04:20 b 20:04:20 b 20:04:22 b 20:04:23 b 20:04:29 b 20:04:34 b 20:04:39 b 20:04:39 b 20:04:49 b 20:05:00 sounds good :) 20:05:11 felixfontein: do they have an issue open somewhere where they're requesting the inclusion? (I don't know if we have the process so formal yet) 20:05:18 but we could stick this decision in there too 20:05:33 #agreed we will reconsider dellemc.openmanage once the rules for inclusion in 2.11 have been set up 20:05:45 geerlingguy: right now they only have a PR with requrest for removal of content from c.g 20:05:54 https://github.com/ansible-collections/community.general/pull/948 20:05:55 https://github.com/ansible-collections/community.general/pull/948 | open, created 2020-09-23T08:52:50Z by rajeevarakkal: Remove DellEMC collections from community.general collectons [affects_2.10,feature,has_issue,module,module_utils,needs_maintainer,needs_revision,new_contributor,plugins,remote_management,stale_ci,tests,unit] 20:06:00 which indirectly (for us) means inclusion in 2.10/2.11 20:06:02 It'd be nice to have some meta issue somewhere, maybe in a community repo 20:06:06 (in general, not just for this one) 20:06:07 sorry, 3.0.0, I keep saying 2.11 :D 20:06:38 Meta issue to track what exactly? 20:06:40 geerlingguy: for the current set of collections, there's https://github.com/ansible/community/issues/539#issuecomment-720085434 which I regularly update 20:06:47 I sympathize that they've had that PR opened since september 20:06:49 * jillr back 20:07:18 wb jillr! 20:07:29 ok, let's start with the big discussion ;) 20:07:37 one sec 20:07:40 ok 20:07:47 just in time :) 20:08:12 * cybette always triple/quadruple check version numbers when compiling bullhorn. having ansible 3.0.0 might make things easier :) 20:08:24 @felixfontein - nice. Probably good to figure out a way to get that list moved into something more manageable once we get further down this path 20:08:42 #agreed we will revisit including dellemc.openmanage after we've had the longer discussion around inclusion criteria. Though at the moment they don't run `sanity` https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 20:08:43 https://github.com/dell/dellemc-openmanage-ansible-modules/pull/174 | open, created 2020-11-18T12:57:28Z by gundalow: WIP Run ansible-test sanity & units 20:08:46 felixfontein: ok, next topic 20:08:48 #topic Criteria for new collections to be included in ansible-3.0.0 20:09:02 #info Proposal: https://github.com/ansible/community/issues/539#issuecomment-729844717 20:09:19 someone wants to present the proposal? abadger1999 gundalow? 20:09:37 So given the schedule calls for getting ansible-3.0.0 out in february and we have people who want to submit their new collections for that, we need to get the criteria for those collections approved ASAP. 20:10:18 I propose that we discuss using the existing checklist: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst as the basis for the cirteria. Discuss today and either vote on it today or the first thing at the next meeting (2 weeks from now) 20:10:42 Then we spend two meetings discussing and voting on any changes to the checklist. 20:11:16 On the December 16th meeting, what have approved is the criteria for ansible-3.0. 20:11:40 Does that overall plan sound good? 20:11:57 If there's no objections, I'll open discussion of the current checklist. 20:12:06 Ideally the bar is low enough to not make it a major hindrance, but high enough that we don't end up with a zillion duplicate things across many collections (e.g. all-the-galaxy-roles-built-into-ansible) 20:12:09 #info We are happy for the inclusion criteria (https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst) to become stricter to help improve the quality of the collections that are shipped in `ansible`. If you have an idea please mention in IRC or raise a PR directly against collection_requirements.rst to clarify & improve 20:13:03 #info Discuss current checklist today, approve it as a basis for the guidelines no later than beginning of meeting on December-2-2020. 20:13:26 #info Discuss and approve changes to the guidelines on December-9 and December-16 20:13:54 #info Guidelines that have been approved by the end of the Dec-16 meeting will be the criteria for new collections in ansible-3.0. 20:14:07 #topic Discuss and approve the current checklist 20:14:15 geerlingguy: yup, it's a balancing act, which makes it difficult 20:14:17 #info The current checklist: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst 20:14:55 having personally gone through that list when standing up community.google and community.kubevirt, there was nothing particularly shocking to me although there are opportunities to make it easier for maintainers to meet the criteria 20:14:58 I think the current checklist is a good starting point! 20:15:08 Is there anything in the current checklist that people think should not be in the list? 20:15:42 Is there anything that peoplefeel must be in the checklist otherwise they cannot vote to approve it as the baseline that we'll build from? 20:15:43 Another thing that I wonder if we don't cover well is what if there are collections that are basically just a bunch of roles? 20:15:44 if you can think of something only after this meeting, that's also fine, we can still remove more things next meeting. or add things. 20:15:57 geerlingguy: and who's nginx install role is the best one? 20:16:24 That document needs a version overhaul based on the semver vote today. 20:16:28 Do we plan on including those in Ansible, or excluding? I don't plan on submitting any, mostly because I believe roles are better separate from Ansible itself, but I guarantee there will be some people/orgs who will want to dump 50+ roles in for managing something or another 20:16:30 abadger1999: I think we should require more details about community/repo management, https://github.com/ansible-collections/overview/issues/126 20:16:49 jillr: agreed 20:16:54 what do we do if a repo shows up with no issue tracker for example? (ie; uses gerrit alone) 20:16:57 I'm not against including role-only collections, but that will definitely be challenging 20:17:18 Hmmm.... 20:17:18 we were discussing how ansible-lint is run when publishing a collection but I forget if it fails publishing if there is an error/warning 20:17:40 One other thing: we don't have anything in there about security — e.g. if there's a CVE filed, it would be nice to make sure there's some documented way of contacting someone who maintains the collection? 20:17:44 I mention that because ansible-lint is missing from that doc 20:17:51 jillr: Does that also mean we're requiring vendors to have their repositories publically available? 20:17:53 also agree we need an overhaul based on semver, for example the #versioning-and-deprecation section 20:18:12 we also need rules about removing collections I guess. when they start violating rules and don't adjust. 20:18:25 abadger1999: that's a really good question, are we considering including collections that aren't f/oss? 20:18:29 #action checklist need an overhaul based on semver, for example the #versioning-and-deprecation section 20:18:41 felixfontein: to a bigger extent that's probably about enforcing (or verifying) compliance 20:18:49 dmsimard: yep 20:18:51 wrt CVE I guess we need an email address 20:19:04 gundalow: +1 20:19:22 #action Need email address of maintainers for CVEs 20:19:35 jillr: I think we 100% need to require the license to be floss. But I hadn't thought about requiring the collection to follow good standards for managing their own community/repo. 20:19:36 what is the recourse if @megacorp.com doesn't respond to the cve email? 20:20:07 Right now the only recourse that I know of for non-compliance is that we kick a collection out. 20:20:22 before or after the next major release? 20:20:28 it's a very good start, but i can't find requirements about unit and/or integration tests? although it should not be mandatory as some modules cannot have integration tests for example, but it will be good to mention it and if it can be handled in some way that should be necessary imho 20:20:29 felixfontein: ideally most/all checklist requirement compliance would be automated so we can easily validate on a regular basis without burning humans out 20:20:29 #action create issue to track CI testing to match Galaxy/AH import testing 20:20:40 If we can come up with other recourses we can document them and decide when each is appropriate to apply. 20:21:06 jtanner: oh that's interesting, like would be have to do a full deprecation cycle? 20:21:39 jtanner: we can only remove in a new major version 20:21:46 otherwise we're violating semver 20:21:52 yeah ... you are all going into semver theory ... does ripping a collection out of a distro without bumping the major comply with semver? 20:22:04 recourses is a different topic 20:22:24 gundalow: that's fair, should that be on the agenda next week? 20:22:38 I feel that repo management stuff is a bit irrelevant as far as the "we want to include high-quality collections" go. Who cares if we have merge commits in our history if our end-result is great? 20:22:41 aminvakil: What would you like to see about unit/sanity tests? 20:23:07 maybe we should open issues for the various points, so people can already add their opinions there. might speed up the next meetings :) 20:23:17 tadeboro: merge commits are a pita to backport/cherrypick .. it's not just a matter of core devs being picky 20:23:28 tadeboro: it's also un-enforceable outside of ansible-collections namespace 20:23:38 gundalow: i'm not sure, but i feel sanity tests alone are not enough. 20:23:45 jtanner: since we only include the galaxy artefact, we don't care whether they use git at all :) 20:23:46 jtanner: But I am doing all that, not the community team. 20:24:08 they can use 3.5" disks as a version control system for what I care about 20:24:19 until you or your sponsor stop funding your projects, then the community team is left holding the responsibility 20:24:24 lol felixfontein :) 20:24:31 If we can get a list I'll create a GH discussion with separate comment for each item 20:24:58 For the record: I also hate merge commits, but that is just my preference. 20:25:00 #action Include strong worded comments about unit tests (module_utils) and integration tests 20:25:07 #chair 20:25:07 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro 20:25:11 aminvakil: I agree that there should be more tests. for existing content we couldn't really ask that, without commiting to write them ourselves, but for new stuff we can ask for that 20:25:14 What else is missing from the checklist? 20:25:29 jtanner: If my collection goes unmaintained, it gets kicked out of Ansible and that is it. 20:25:38 felixfontein: +1 20:25:51 The bar can be continually raised, older content would be grandfathered in, though we can help improve them over time 20:26:04 tadeboro: people can still manually install the kicked out collection if they really want to use it, so kicking out is not making it impossible to use it anymore 20:26:22 felixfontein: But at that point, it is not your problem anymore. 20:26:31 tadeboro: so we shouldn't mind kicking stuff out too quickly :) 20:26:47 * geerlingguy afk for a couple min 20:26:50 I'd still be wary of /too easily/ kicking collections out 20:26:55 at the expense of breaking users 20:26:57 tadeboro: you can configure the tools to just show it as if it were a squash/merge 20:26:58 I think we are going off topic slightly 20:27:19 dmsimard: I don't think we do, but as opposed to removing content from a collection, removing a collection from ansible can easily be worked around 20:27:42 I think there's definitely a conversation to be had around test criteria, but we can have that in a discussion thread probably 20:27:55 jillr: I think that's a good idea! 20:27:57 felixfontein: right -- I just mean that whatever recourse we end up with, there should be warnings/attempts at coming back into compliance 20:28:01 if the plan is to create threads for these items 20:28:10 #info https://hackmd.io/4hCPYtfLQQO4O9_UfcfhUQ 20:28:14 dmsimard: definitely. kicking out is a last resort 20:28:19 ++ 20:28:29 I haven't added everything that's being discussed here yet. 20:28:51 who wants to collect the list and create issues? 20:29:06 afk to pick up kids o/ 20:29:17 let's mention all issues in the community agenda issue, or have a meta issue (whoever creates the issues can decide what they prefer) 20:29:32 felixfontein: I'll do that tomorrow 20:29:34 and if someone else can think of something that hasn't been mentioned yet, simply create a new issue (and also mention it) 20:29:51 the next meeting is in two weeks, so there's plenty of time to think about all these things 20:30:16 does that sound reasonable? 20:30:19 gundalow: thanks a lot :) 20:30:38 felixfontein: sounds good to me 20:30:47 felixfontein: two weeks == just enough time for me to realize there's another one of these meetings coming up :D 20:31:11 :) 20:31:46 Is there anything else, I need to drop off 20:31:57 One thing: 20:32:16 When you write up your proposals for changes: please categorize in this way: 20:32:27 (1) I will not vote to approve the existing checklist without this 20:32:45 (2) I want to get this change added but it does not block the existing checklist being approved 20:33:51 I guess you can also add that classification to other people's proposals 20:34:00 If we have a ton of things in category (1), I think we'll have to go through and re-categorize them so please use that category sparingly.... It's definitely okay not to have any proposed changes that fall into that. 20:35:17 sounds good to me 20:35:22 anything else for this topic for today? 20:35:29 Maybe a bit off-topic, but still: are there any existing content-inclusion requests? Because when I talked to people who intend to start using collections, they will install them manually and possibly keep it pinned down to the exact version that they verified works for them. 20:36:04 Spending a ton of time and then getting no including requests might be a bit silly. 20:36:13 if not, I'd propose we spend a little time on https://github.com/ansible/community/issues/539#issuecomment-715496088, since the last c.g 1.x.0 release will happen very soon (i.e. before the next meeting) and the question becomes irrelevant if that passed 20:36:14 We don't have any publically that I know of. I asked the internal partner team today and they think there's about ~10 collections that partners will want to get added for 2.11.0 20:36:36 s2/11/0/3.0.0/ ;-) 20:36:46 heh 20:36:48 tadeboro: there are some plans, like moving the hashi_vault plugin into its own collection, and the hetzner modules too 20:37:05 I don't know how many community-non-partner collections there are waiting for us to decide on this. 20:37:08 felixfontein: But those are not new new. 20:37:24 tadeboro: ah I think I read your question wrong 20:38:24 felixfontein: I probably wrote it down badly. Getting late in CET ;) 20:38:32 tadeboro: it is :) 20:38:45 felixfontein: i think as it seems the original author of issue has not asked about that in a while it's fine to postpone it to the next release. 20:38:52 community.sops would like to be included in 2.11 :) 20:39:11 #action ALL: Please write up your proposals for changes to https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst categorized by whether they should block approval of the checklist or not. We'll start discussing and voting on changes next meeting 20:39:15 aminvakil: the next release will be 2.0.0, which accepts breaking changes anyway :) 20:39:54 #info Reminder: next meeting is in two weeks, i.e. December 2nd, starting at 19:00 UTC 20:39:56 well let's put it in 2.0.0, i don't think it's worth to discuss it after a 40 minute overdue:) 20:40:06 aminvakil: fine for me :) 20:40:22 #action Write your proposals as an issue and mention it in the community agenda ticket https://github.com/ansible/community/issues/539 20:41:47 Cool. 20:43:06 ok. open floor? 20:43:12 +1 20:43:17 #topic open floor 20:43:24 does anyone have something for the open floor? 20:43:43 if yes, quickly say so so we don't close before you finished writing your stuff ;) 20:43:50 #chair 20:43:50 Current chairs: abadger1999 acozine aminvakil briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal samccann tadeboro 20:44:09 ;-) 20:44:36 the template should be liberally licensed 20:44:46 Nothing from me (except sorry for pushing some big discussions onto the agenda at the last minute) 20:45:09 better to get them in and get the discussion started 20:45:13 cyberpear: meaning the templates for a new collection? I agree 20:45:17 I opened an issue on the repo, but missed any response 20:45:19 we can't start any younger, as they say 20:46:02 right now if you don't want GPL, you have to invent your own template 20:46:12 cyberpear: Can you link to that? 20:46:27 (there's so many repos I can't remember where everything lives) 20:46:38 https://github.com/ansible-collections/collection_template/issues/18 20:46:53 https://github.com/ansible-collections/collection_template/issues/18 20:47:02 I think the license in the repo is meant as the default license for a new collection, not as a license for the template itself 20:47:37 I think I count 8 contributors. 20:47:38 we should make it explicit 20:47:44 cyberpear: It is quite hard to write a non-GPL collection if you have a non-module plugin of any kind. 20:47:45 if everyone sees it that way, we should clarify that so that we don't prevent people using the template because they don't want to license their collection as GPL 20:48:09 tadeboro: if you just have roles, playbooks and modules, it's doable :) 20:49:17 #info need to write some text to explain what license the template is under and what licenses the collection owner can place it under 20:49:27 abadger1999: I'm not sure what the real intend of the template was, do you agree with my statement that GPL was not meant as a license of the template? 20:49:49 #info need to CC all of the current contributors (8) to the templates about whether we can license it under a liberal license (3-clause BSD maybe?) 20:50:05 Is it even possible to license template under a different license from the final (user-provided) content? 20:50:28 felixfontein: I think it probably doesn't matter what our intentions were :-( Because it's confusing, we have to get approval from everyone who might have thought they were contributing under the GPL. 20:50:40 abadger1999: true, but that should be doable :) 20:51:27 tadeboro: Some licenses allow you to sublicense/embed the code in your own work which is under a different license. 20:51:38 So Ithink those are for a template. 20:52:19 abadger1999: I was thinking more in the context of hosting content on GitHub without confusing the heck out of potential users and/or contributors. 20:53:14 btw, for repos created from a template, is it possible to remove this `generated from ansible-collections/collection_template` note? 20:53:15 Yeah.... there is the potential for high confusion factor. 20:53:41 my albeit vague recollection is that the license within the template was an 'example' license... not a license for using the template itself 20:55:04 who is working on the template? 20:56:08 abadger1999: everybody and nobody :) 20:56:25 i.o.w. gundalow ;) 20:56:39 looks like gundalow has done the most with it - https://github.com/ansible-collections/collection_template/graphs/contributors 20:56:49 Maybe an "interactive" template (for example, `ansible-galaxy collection init` with a bit more content) would be a better long-term solution? 20:56:52 i did some on the readme 20:57:04 btw, I added a deprecation with module.deprecate but running collection integration tests, I don't see any message. I also tried module.warn which does show. Is this expected? 20:57:22 tadeboro - dmsimard had mentioned maybe doing something similar with `cookiecutter` 20:57:29 if you look at the 'raw' version of the readme - it has a lot more info in comments. Something tells me folks aren't doing that tho so maybe that needs to be pulled out and made visible 20:58:03 resmo: deprecation warnings are only shown the first time, so maybe you didn't look at the right invocation 20:58:09 resmo: but in general it should show up 20:58:50 samccann: I was thinking more about the issue with the license. Interactive template can prompt user for a license and then install that while keeping its content licensed however it feels like. 20:59:31 felixfontein, I checked but can not find any. 20:59:38 resmo: url? 20:59:50 resmo: This is how we check in our integration test for the deprecations: https://github.com/sensu/sensu-go-ansible/pull/230/files 21:00:13 "We still want to support ansible < 2.9.10" - my condolences :) 21:00:25 the existing collection template allows a developer to create the repo will all those bits using github's 'create repo from template' option 21:01:04 I dunno `cookiecutter` etc so don't know if it allows for that same repo creation... or if it matters? 21:01:10 tadeboro, similar to what I do (also added collection_name, but does not show up with ansible-test integration version 2.11.0.dev0 21:01:28 when I switch to warn, I see warnings. 21:01:57 let me test with ansible-2.10 21:02:07 samccann: That is true. But you still need to fill in and replace some things in that template while the cookie-cutter variants can interactively prompt for info. 21:02:19 maybe ansible-test hides deprecations? 21:02:53 samccann: But both solutions are fine as far as I am concerned as long as the licensing is not confusing. 21:04:14 samccann: But I always used "generators" for such things: bison for parsers, molecule uses cookie-cutter, ... 21:05:02 given we are 2 hrs into a 1 hr meeting - is there something we can do/decide here? or should we sprinkle some infos and think Deep Thoughts about it all for the next meeting? 21:05:19 felixfontein: Welcome to the world of enterprise software ;) 21:05:55 samccann: I think not. 21:05:58 #endmeeting