19:00:24 #startmeeting Ansible Community Meeting 19:00:24 Meeting started Wed Mar 17 19:00:24 2021 UTC. 19:00:24 This meeting is logged and archived in a public location. 19:00:24 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:24 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:24 The meeting name has been set to 'ansible_community_meeting' 19:00:25 #topic Agenda https://github.com/ansible/community/issues/539 19:00:25 abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping! 19:00:30 hi 19:00:31 * gundalow waves 19:00:34 \o 19:00:35 o/ 19:00:37 #chair abadger1999 gundalow dmsimard andersson007_ 19:00:37 Current chairs: abadger1999 andersson007_ dmsimard felixfontein gundalow 19:00:37 o/ 19:00:39 o/ 19:00:43 o/ 19:00:44 o/ 19:00:46 #chair tadeboro cyberpear cybette 19:00:46 Current chairs: abadger1999 andersson007_ cyberpear cybette dmsimard felixfontein gundalow tadeboro 19:00:52 #chair briantist 19:00:52 Current chairs: abadger1999 andersson007_ briantist cyberpear cybette dmsimard felixfontein gundalow tadeboro 19:00:59 #topic Updates 19:00:59 #info Ansible 4.0.0a1 has been released 19:01:26 any more furniture? :) 19:01:36 + kitchensink 19:01:42 :) 19:01:46 o/ 19:01:51 #chair samccann 19:01:51 Current chairs: abadger1999 andersson007_ briantist cyberpear cybette dmsimard felixfontein gundalow samccann tadeboro 19:02:01 * dericcrago waves 19:02:07 #chair dericcrago 19:02:07 Current chairs: abadger1999 andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow samccann tadeboro 19:02:40 #info Ansible Contributor Summit 2021.03 playlist https://www.youtube.com/playlist?list=PL0FmYCf7ocraIwuMDD_TceUMneSiy3Hi1 19:03:08 o/ sorry I'm late 19:03:12 it was a really nice summit :) 19:03:14 #chair jillr 19:03:14 Current chairs: abadger1999 andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro 19:03:19 jillr: still in time :) 19:03:20 +1 19:03:31 +1 thanks to everyone for great summit 19:03:42 summit was great 19:03:51 yeah great job 19:03:51 cybette++ thanks for putting the playlist! 19:04:01 feeling of community 19:04:22 cyberpear: my pleasure! 19:04:25 and seeing more faces :) 19:05:02 Summit was great! Glad the videos were posted since I missed some of them 19:05:11 #chair apple4ever 19:05:11 Current chairs: abadger1999 andersson007_ apple4ever briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro 19:06:15 cybette: Do you have an IRC specific survey link you'd like to share? 19:06:17 any more updates? 19:07:06 gundalow: I actually didn't get a link for IRC... Gwmngilfen? 19:07:28 cybette: Just wondered if you wanted to share a link here 19:07:50 #info If you attended Contributors Summit please check your email for a survey link. Feedback is really important to us 19:07:59 felixfontein: Don't think there are any other updates 19:08:03 ok :) 19:08:09 #topic Ansible Engineering Steering Committee 19:08:09 #info From next week on, this meeting will (also) be the official weekly meeting of the Ansible Engineering Steering Committee 19:08:41 I don't know if anyone prepared a more elaborated announcement for this 19:08:43 Thanks to ompragash for making this happen. And the dozens of people that have helped get us to this point 19:09:26 indeed! thanks ompragash! 19:09:38 I believe there will be some details in The Bullhorn tomorrow 19:09:40 ompragash++ ! 19:09:44 The meeting will continue to be a lot like it is now but the steering committee members will be present and will discuss and vote on proposals 19:09:53 Hip hip hooray ompragash! 19:10:14 ompragash++ for all the work on Steering Commitee! 19:10:14 cyberpear: Karma for ompragash changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:12:49 #topic Inclusion request review day: Wednesday, March 24th 19:13:15 we're planning a inclusion request (https://github.com/ansible-collections/ansible-inclusion/discussions) review day for next week's Wednesday 19:13:32 the current question is: which time(s) should we do this? 19:13:41 There was a good suggest from IRC that given we are getting close to the 4.0.0 cut off we should spend some time reviewing the open request (above URL) 19:13:53 (I think tadeboro brought that up) 19:14:14 o/ 19:14:17 #chair acozine 19:14:17 Current chairs: abadger1999 acozine andersson007_ apple4ever briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro 19:14:20 ah, yes, thanks 19:14:24 I'll be there during north american eastern time and happy to pitch in to help review :) 19:14:36 sorry I'm late, I saw the ping and then got into fixing some CI failures 19:14:38 i'm going to review all tomorrow 19:14:59 andersson007_: thanks for that ++ 19:15:03 andersson007_: thanks! 19:15:06 `dellemc.enterprise_sonic` brings up a question of naming standards for collections included in Ansible... do we need the "enterprise" part there? 19:15:14 fixing CI is always time well spent 19:15:19 the community is always welcome 19:15:21 maybe the question is then more: when do the Europeans here want to start? ;) 19:15:26 (but maybe a separate discussion) 19:15:29 cybette-clock says: we're 15 minutes into the meeitng! 19:15:31 afternoon works for me 19:15:53 oops cybette-clock typo-ed 19:16:16 cyberpear: it looks like it might be the actual product name 19:16:47 I am available for most of the day minus some meetings. 19:16:59 cyberpear: collection names are free form and really up to the authors I think... unless it's inappropriate or vulgar that is 19:17:07 I've got a meeting in the US-West morning otherwise I'm free all of my day 19:17:08 cyberpear: good question. I have no idea what that product is. they seem to use Enterprise with it all the time though: https://www.dell.com/en-us/work/shop/productdetailstxn/sonic (and they don't seem to do that with other products) 19:17:26 more generally, do we care if collection owners want to name their collections `my.fabulous_collection` or `our.buzzword_bingo_collection`? 19:17:46 how about starting around lunchtime in CET, and continue as long as people are still around? 19:17:49 my question was whether we wanted more specific guidelines to be included in the Ansible package bundle 19:17:59 cyberpear: ah, gotcha 19:18:44 sonic is an opensource project, and these seems to be dell's enterprise version of it 19:18:52 Shouldn't contain the term `ansible` 19:18:53 s/these/this/g 19:19:05 dellemc.enterprise_sonic_ansible_modules ;) 19:19:15 so maybe it brings us back to the community.okd vs redhat.openshift collection names for the same collection 19:19:22 type that 10 times fast ;-) 19:20:02 I'd like to strongly encourage not having different collection names for the "supported product" and the "community project" to allow better compatibility 19:20:16 I agree on that 19:20:21 +1 19:20:28 the guidance that RH gives partners is community.{projectname} OR {vendorname}.{productname} OR {projectname}.{projectname} 19:20:31 shouldn't it be the job ob of dellemc to manage their namespace? if they want to name a collection "dellemc.enterprise_something" that's their thing, isn't it? 19:20:33 but let's maybe switch topic first :) 19:20:45 seems sensible to do something at least similar in community 19:20:46 does starting next week 12:00 UTC sound good? 19:20:51 mariolenz: I lean towards that, yeah. 19:20:53 heh, what is our official topic felixfontein? 19:20:55 tadeboro: gundalow: andersson007_: ^ 19:21:04 (sorry for derailing) 19:21:05 acozine: Inclusion request review day 19:21:07 13:00UTC, so post (my) lunch? 19:21:13 gundalow: also fine for me! 19:21:17 I am fine with afternoon and evening torture ;) 19:21:28 tadeboro: You typod "fun" 19:21:35 hee hee 19:21:35 #agreed Inclusion request review day will start 13:00 UTC on Wednesday, March 24th 19:21:40 works for me; I'll get some reviews in before then since I'll be online latest 19:21:46 woot 19:21:47 #topic Collection naming 19:21:48 just on irc or do you need any conference type setup 19:21:49 Thanks all 19:21:54 cybette: just IRC 19:21:56 ok, so let's continue with collection names ;) 19:22:02 Also, that dells collection is certified and available on AH. Do we want to force maintainers to maintain the same content under different names? 19:22:13 cyberpear: I think IRC should be fine 19:22:34 tadeboro: maybe they want to rename their supported collection as well ;) 19:22:39 I wouldn't force them though 19:22:40 tadeboro: I would vote very much No on that, in light of the okd situation :) 19:22:41 the upstream vs certified collection namechange would make FQCN a bit of a problem 19:22:49 I think it's better for Galaxy & AH to have the same name 19:22:53 yup as samccann says 19:23:06 agreed 19:23:26 is the dell collection currently two different names for hte same content? 19:23:30 I also agree, as long as the name isn't absolutely horrible I'd prefer if AH and galaxy use the same name 19:23:31 There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. 19:23:41 (and if it is horrible, I wonder who accepted that for AH :D ) 19:24:01 gundalow: why do you list 4 things? :P 19:24:13 felixfontein: :) 19:24:15 so there's 2 issues. 1) name collections the same for "supported" vs "community" to make playbooks work with either without further changes 2) make good naming guidelines for collections to be included in Ansible package bundle 19:24:44 and these issues are sometimes conflicting 19:24:45 the example is https://galaxy.ansible.com/dellemc/enterprise_sonic, right? 19:25:14 tadeboro: is it the same name on AH? 19:25:26 I would keep out of the naming bussiness and just make sure names are not offensive. Apart from that, I would let the authors have their way. 19:25:37 Same on AH, https://cloud.redhat.com/ansible/automation-hub/repo/published/dellemc/enterprise_sonic 19:25:55 acozine: Yes, the same name is in AH. 19:26:02 tadeboro: That has my vote as well. 19:26:04 I suspect most collection maintainers don't want the hassle of "which name do I use to publish to which platform, again?" 19:26:05 currently I only know of one collection that uses two different names, and that's community.okd vs. redhat.openshift 19:26:08 OK, so nothing to do there 19:26:15 i would suggest names based on technology vs 'supprt status' but 'ship sailed, sunk, refloated and is now a beached casino' 19:26:15 tadeboro: I'd generally agree except that we push folks to use fqcn in many places and you can't use unqualified without declaring `collections:` 19:26:25 bcoca: well put 19:26:38 bcoca++ 19:26:48 felixfontein: in that case, were legal issues .. redhat. cannot be used for 'official ones' 19:27:18 but that colleciotn has had more renames than puff daddy 19:27:20 I think foreman is also available under two different names. 19:27:21 bcoca: I heard about legal issues, but I'm not sure I really understood what's the issue :) 19:27:25 it's probably unlikely many folks not Red Hat will have the same trademark issues we do, so keeping them the same in galaxy and AH should be fine in most cases 19:27:35 perhaps the caveat that nothing in AH should be named 'community.' ? 19:27:40 `ansible.okd` or `ansible.openshift`? (but yes I understand folks might not want to tackle that right away) 19:27:42 felixfontein: i would have asked, but didnt want to know 19:27:56 but could redhat.openshift be used on community galaxy? 19:28:01 Do we even need to get into naming? 19:28:02 felixfontein: no 19:28:15 maybe we should discourage having anything `community.*` that could ever possible become supported? 19:28:19 jillr: so redhat.openshift cannot be used on galaxy, and community.okd cannot be used on AH? 19:28:27 felixfontein: trademakrs must be defended by owner or they get lost, so not advisable to use company names 19:28:43 gundalow: I don't think we do unless someone shows up with a problematic name (ie; tries to use the anisble namespace) or some special circumstance 19:29:00 felixfontein: in a tl;dr, correct 19:29:09 I am not a lawyer :) 19:29:10 cool 19:29:22 jillr: and renaming to ansible.okd or something like that (that can be used in both places) is not an option? 19:29:38 felixfontein: correct, but for different reasons :) 19:29:39 https://cloud.redhat.com/ansible/automation-hub/repo/published/redhat/satellite is downstream of foreman.foreman. 19:29:49 the ansible namespace is special 19:29:56 too many ways ... 19:30:02 jillr: or anything else than ansible :) 19:30:15 i was happier when we had banned the use of ansible as namespace .... 19:30:24 heh, if only the lawyers knew how many hours would be burned by forcing bad naming of things 19:30:27 but relevant to our interests, we don't need to manage or gatekeep collection namespaces in the community unless some special circumstance happens 19:30:28 Ok 19:30:29 ..... 19:30:31 #chair bcoca geerlingguy 19:30:31 Current chairs: abadger1999 acozine andersson007_ apple4ever bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr samccann tadeboro 19:30:34 cybette-clock says - 9 mins on topic "Collection naming" and 30 mins into meeting! 19:30:40 What problem are we trying to solve in this topic? 19:30:45 "naming things is easy" 19:30:51 lol geerlingguy 19:31:17 "I would like to paint the bike shed purple" 19:31:19 all new collections to be accepted to galaxy must have names w/o voewls and at least 2 Ks 19:31:21 original question was "why is Dell using `enterprise` in their collection name, is that a problem, and if so what do we do about it" 19:31:25 Naming them is easy, renaming them after you realize you screwed up is hard ;) 19:31:41 to which we answer: we don't know, no, and nothing 19:31:48 jillr: no, malva, purple is passe! 19:31:51 acozine: 1) because it's part of the product name and it's what they use on AH 2) IMO no 3) n/a 19:32:02 can we agree that it is desirable that galaxy and AH collection names should be identical if possible? 19:32:03 OK, so sound like the original question has been answered 19:32:06 jillr: +1 19:32:10 felixfontein: +1 19:32:10 felixfontein: +1 19:32:13 +1 19:32:24 +1 19:32:29 +1 19:32:31 apparently we can't enforce it, but at least we can express that we'd like that :) 19:32:35 VOTE: that it is desirable that galaxy and AH collection names should be identical if possible? 19:32:41 +1 19:32:41 +1 19:32:42 +1 19:32:44 +1 19:32:44 +1 19:32:44 yep 19:32:45 +1 19:32:47 +1 19:32:50 +1 19:32:50 +1 19:32:51 #chair mariolenz 19:32:51 Current chairs: abadger1999 acozine andersson007_ apple4ever bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr mariolenz samccann tadeboro 19:32:54 +1 19:32:54 +1 19:33:00 +1 19:33:02 ship sailed? 19:33:06 +1 19:33:12 bcoca: it is, but still... :) 19:33:18 bcoca: This is why "if possible". 19:33:21 I would even consider making a rule "all future collections *must* be named the same if they appear in both" 19:33:30 and goes against policy of other teams, so not sure how relevant 19:33:33 unless someone would intentionally like to sabotage Ansible's UX 19:33:53 geerlingguy: pretty sure several are actively on it 19:33:59 "if possible" is a bad thin, people will always have excusions why it isn't 19:34:00 whom do we need to convince/bribe/... to avoid such name differences in the future? :) 19:34:03 "Pay us money to have support, and you get to rewrite all your playbooks!" 19:34:05 `ansible.libreoffice` vs `ansible.openoffice` 19:34:26 geerlingguy++ yes. For the ones that are named differently, I'd like to slap some magic compat sauce to make content written for either work with the other 19:34:41 I don't think we need to keep rehashing the naming frustrations 19:34:54 i would avoid the ansible. namespace also 19:35:06 #agreed it is desirable that galaxy and AH collection names are identical if possible 19:35:12 jillr: sorry, just still hot and bothered about it (will be for some time) since I was personally involved 19:35:15 We don't have anything actionable on this topic afaict right now 19:35:20 But we just included ansible.utils ... ;) 19:35:50 btw, are ansible.posix and ansible.utils Supported? 19:35:53 geerlingguy: :) so am I, but in the interest of respecting the time of the folks in this meeting I think we should move on- 19:35:59 felixfontein: one is 19:36:06 ansible.posix 19:36:12 ah 19:36:17 so ansible.utils isn't? 19:36:32 ansible.utils will probably be once other certified collections start using it. 19:36:38 ok 19:36:54 as for the next topic, I have one that is hopefully uncontroversial: 19:36:55 #topic Collection guidelines: disallow validate-modules:no-log-needed ignore.txt entries 19:36:55 well, ansible.posix is 'maintained' but has no maintainers 19:37:00 #info https://github.com/ansible-collections/overview/pull/158 19:37:01 https://github.com/ansible-collections/overview/pull/158 | open, created 2021-03-12T06:16:38Z by felixfontein: Collection guidelines: disallow validate-modules:no-log-needed ignore.txt entries 19:37:06 bcoca: I think andersson007_ got drafted ;) 19:37:20 oh ... they people need to stop pinging me about it 19:37:28 andersson007_: you have my condolences 19:37:44 :)) 19:37:54 bcoca: it would still be great if you could provide technical help :) 19:38:07 #158 LGTM 19:38:08 #itsonmylist 19:38:20 +1 #158 19:38:36 As you might have noticed (if you're maintaining a collection you most certainly will have), there's a new validate-modules test which checks for option names that could contain a secret that should have no_log=True 19:38:44 I can't comment on implementation, but I support the intention 19:39:03 +10k 158 19:39:08 the PR essentially forbids to ignore that error. people should use no_log=False for false-positives, and no_log=True for actual secret-containing options 19:39:09 +1 19:39:20 +1 PR 158 (to avoid people disabling the test instead of adding `no_log=False` to false positives) 19:39:26 +1 19:39:29 since we already have a list of ignored errors we don't want to see, I suggest adding this one :) 19:39:34 +1 and thanks for the explanation 19:39:59 any comments on the wording? 19:40:10 (it's simple enough that I shouldn't have screwed it up too badly ;) 19:41:32 Wording is fine with me. I'm happy there's information on how to flag false positives :-) 19:41:58 a "false positive" in this case is something that looks like a secret but isn't really 19:42:00 ? 19:42:03 acozine: yes 19:42:10 +1 the idea sounds good and there's a way to opt-out/false-positive-flag 19:42:15 +1 19:42:20 and the solution is to mark it `no_log` as well? 19:42:30 like `key` when used as a configuration key to look up - that's not secret at all, but will be flagged 19:42:31 oh,I see 19:42:40 acozine: no_log=False, as opposed to no_log=True 19:42:45 realy needs to read ``validate-modules:no-log-needed`` to solve: CONTENT CENSORED BY NO LOG 19:43:02 it's to mark it `No_log=False` which says, basically "We thought about this, we know it looks secret, but it's not, we really meant it htis way" 19:43:16 yeah, that makes sense 19:43:25 acozine: yes :) 19:43:29 it's a lot of negatives piled up on top of each other 19:43:35 but it makes sense in context 19:43:39 :) 19:43:52 vote? 19:43:55 VOTE: should we merge https://github.com/ansible-collections/overview/pull/158 ? 19:43:59 +1 19:43:59 +1 19:44:01 +1 19:44:02 +1 19:44:06 +1 19:44:09 +1 19:44:10 +1 19:44:10 +1 19:44:17 +1 19:44:24 +1 19:44:25 MERGED 19:44:32 🎉 19:44:33 \0/ 19:44:37 #agreed gundalow merges the PR 19:44:39 :) 19:44:42 heh 19:44:42 thanks a lot! 19:44:49 heh 19:44:53 +1 19:44:54 hope nobody looks at the timestamps too closely ;) 19:45:04 +1 19:45:15 belated +1 19:45:28 #topic Python version requirements: https://github.com/ansible-collections/overview/pull/151 19:45:29 https://github.com/ansible-collections/overview/pull/151 | open, created 2021-01-25T12:48:11Z by Ompragash: New Policy Regarding Python Compatibility for Collections 19:45:43 Ompragash added a new version of the proposal as a comment to the PR 19:45:46 is this 3d attempt? 19:46:05 cybette-clock says we're 45 mins into the meeting! 19:46:16 it still needs conversion to RST and being incorporated in the PR itself 19:46:45 I hope that we can vote on it and merge it next time, so if someone wants something changed, please comment on the PR, or here right now so we can discuss it :) 19:48:25 I think it should say 3.5 or higher, not 3.6 or higher 19:49:12 is https://github.com/ansible-collections/overview/pull/151#issuecomment-801161881 good? 19:49:22 (ignoring md vs RST 19:49:24 ) 19:49:49 (ah, it says that, I had to scroll to see it) 19:50:00 s/should/must/ in the controller environment section 19:50:33 Maybe list the "uses a library which is not compatible with an old version of python" exception explicitly 19:50:59 should other-environment also use "must" in place of "needs to"? 19:51:43 jillr: yes, for consistency 19:51:44 +1 abadger1999 , that one applies to my collection specifically 19:51:45 jillr: yeah, good point 19:52:03 for the library, I'd wonder whether there's an older system version of the library that's still being patched by the distro 19:52:47 cyberpear: I'm sure debian will have some ;) 19:52:59 next to their Ansible 2.4? ;) 19:53:10 cyberpear: I'd prefer to stick with what the library itself supports. maybe RHEL will patch boto3 for py2.7, but that doesn't help me support ubuntu, debian, etc for example 19:53:13 do we really use the term `demilitarized zone` for cloud environments 19:53:17 ? 19:53:33 For network environments, yes. 19:53:37 acozine: the DMZ in this case isn't in the cloud env, but on the user's local/corp network 19:53:47 DMZ is not about cloud here. 19:53:50 acozine: where? DMZ has a specific meaning in networking 19:54:07 https://en.wikipedia.org/wiki/DMZ_(computing) 19:54:13 if it's an industry term, then we can carry on 19:54:14 cyberpear: "the controller might run on one machine inside a demilitarized zone which can't directly access the cloud machines" 19:54:18 like if I can't connect to AWS directly from my laptop at work, I have to jump host through a dmz first 19:57:02 so do we want something like "On the controller node, collection MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. We also suggest to support Python v3.5 if in case the required libraries support this version." for controller-environment? 19:57:56 +1 19:58:14 though hmm, it uses controller *node* and not controller *environment* 19:58:16 maybe just "controller" vs "controller node"? 19:58:23 so do we want something like "In the controller environment, collection MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. We also suggest to support Python v3.5 if in case the required libraries support this version." for controller-environment? 19:58:32 +1 19:58:35 `On the controller node, collections MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. Collections SHOULD also support Python v3.5 if all required libraries support this version.` 19:58:37 oh good catch, +1 19:58:53 and similar for the `other environment` 19:59:45 (my suggestion makes the phrasing parallel - collections MUST x; collections SHOULD y - makes it easier to understand) 20:00:32 "In the controller environment, collections MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. Collections SHOULD also support Python v3.5 if all required libraries support this version." 20:00:42 cybette-clock says 15 mins on topic "Python version requirements" and 1 HOUR into meeting 20:00:59 +1 on MUST and SHOULD 20:01:33 +1 20:01:40 +1 20:02:03 "In the remote environment, collection MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. Collections SHOULD also support Python v2.6 and v3.5 if all required libraries support this version. 20:02:15 (s/collection/collections) 20:02:43 VOTE: should we use the above verisons (with the plural s fixed in the second)? 20:02:49 +1 20:02:51 +1 20:02:54 +1 20:02:56 I guess we can vote on this since it seems as good as anything else we will come up today. 20:02:56 +1 20:02:57 +1 20:02:58 ++1 20:03:04 +1 20:03:08 +1 20:03:10 felixfontein: are we using remote or managed? 20:03:15 +1 20:03:22 ah crap 20:03:24 *other* 20:03:27 not remote/managed 20:03:40 "In the other environment, collections MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. Collections SHOULD also support Python v2.6 and v3.5 if all required libraries support this version. 20:03:52 +1 20:04:00 (or should we always write other-environment, controller-environment with dash?) 20:04:04 `managed` is also used in the Note section 20:04:28 (would be good to add a clarification what "other" can be, imo, like a note) 20:04:38 +1 the general text though, with whichever term we go with 20:04:59 jillr: I tihnk there 'managed' is fine, since other-environment is usually the managed node, but it doesn't have to be 20:05:03 andersson007_: it is defined earlier with some examples: - `other-environment`: It is possible, even if uncommon in practice, for the plugins/modules to run in a different environment than ansible-core itself. 20:05:22 abadger1999: cool, thanks 20:05:32 #agreed "In the controller environment, collections MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. Collections SHOULD also support Python v3.5 if all required libraries support this version." 20:05:39 #agreed "In the other environment, collections MUST support Python 2 (version 2.7) and Python 3 (Version 3.6 and higher), unless required libraries do not support these versions. Collections SHOULD also support Python v2.6 and v3.5 if all required libraries support this version. 20:05:45 ok. 20:05:52 so let's see how that text looks like next week ;) 20:06:04 I guess it's time to close this meeting, resp. switch to open floor! 20:06:09 #topic open floor 20:06:18 is there anything else someone wants to discuss today? 20:06:48 I just wanted to provide a quick update on the ubuntu PPA 20:07:24