19:00:17 <felixfontein> #startmeeting Ansible Community Meeting
19:00:17 <zodbot> Meeting started Wed Feb  3 19:00:17 2021 UTC.
19:00:17 <zodbot> This meeting is logged and archived in a public location.
19:00:17 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:17 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:00:17 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
19:00:17 <felixfontein> 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:25 <dmsimard> \o
19:00:28 <jillr> o/
19:00:30 <cybette> o/
19:00:39 <samccann> o/
19:00:46 <abadger1999> Good day!
19:00:48 <lmodemal> Hello there \o/
19:00:51 <felixfontein> #chair dmsimard jillr cybette samccann abadger1999 lmodemal
19:00:51 <zodbot> Current chairs: abadger1999 cybette dmsimard felixfontein jillr lmodemal samccann
19:01:28 <felixfontein> #topic Updates
19:01:34 <cyberpear> ol
19:01:37 <felixfontein> #info Ansible 3.0.0 beta 1 has been released
19:01:37 <felixfontein> #info Several new collections have been included in Ansible 3: t_systems_mms.icinga_director, sensu.sensu_go, community.sops, inspur.sm, dellemc.openmanage, and ansible.utils!
19:01:41 <felixfontein> #chair cyberpear
19:01:41 <zodbot> Current chairs: abadger1999 cyberpear cybette dmsimard felixfontein jillr lmodemal samccann
19:01:50 <gundalow> o/
19:01:54 <felixfontein> #chair gundalow
19:01:54 <zodbot> Current chairs: abadger1999 cyberpear cybette dmsimard felixfontein gundalow jillr lmodemal samccann
19:02:29 <dmsimard> We're up to over 80 collections in 3.0.0!
19:02:36 <felixfontein> yay \o/
19:02:47 * dericcrago waves
19:02:55 <felixfontein> #chair dericcrago
19:02:55 <zodbot> Current chairs: abadger1999 cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann
19:02:56 <lmodemal> Wow :)
19:03:49 <gundalow> dericcrago: any PPA update?
19:05:17 <felixfontein> some potential topics we can discuss today:
19:05:18 <felixfontein> Policy: 1) Python policy (https://github.com/ansible-collections/overview/pull/151), 2) docs clarifications (https://github.com/ansible-collections/overview/pull/152), 3) require tags for releases (https://github.com/ansible/community/issues/539#issuecomment-770351340)
19:05:18 <github-linkbot> 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:05:19 <github-linkbot> https://github.com/ansible-collections/overview/pull/152), | open, created 2021-01-27T20:17:20Z by dmsimard: Improve clarity of the documentation requirements
19:05:22 <felixfontein> Other: 1) maintenance of community.network, 2) schedule for Ansible 4
19:05:26 <acozine> o/
19:05:38 <dericcrago> I was hoping to have the big reveal today, but I'm still working through some things, bionic, focal, and groovy _should_ be ready to go by the end of the week
19:05:39 <felixfontein> (and plenty of not so urgent leftovers from the past ;) )
19:05:44 <felixfontein> #chair acozine
19:05:44 <zodbot> Current chairs: abadger1999 acozine cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann
19:06:42 <abadger1999> #info ansible PPAs are progressing nicely.  ETA: end of the week for bionic, focal, and groovy
19:07:30 <felixfontein> cool!
19:07:41 <abadger1999> Thanks dericcrago !
19:08:23 <dericcrago> I believe `straight.plugin` will keep us from _easily_ supporting anything before bionic - https://packages.ubuntu.com/search?keywords=straight.plugin&searchon=names&suite=all&section=all
19:09:22 <dericcrago> but I guess that's more of an ansible-(base|core) problem
19:09:22 <tadeboro> I will be a bit late. Reading books with kiddos before bed.
19:09:47 <felixfontein> #chair tadeboro
19:09:47 <zodbot> Current chairs: abadger1999 acozine cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro
19:10:01 <felixfontein> abadger1999: do you want to begin with Ansible 4?
19:10:18 <cybette> ding! 10min in Updates, 10min in meeting
19:10:43 <abadger1999> Sure.
19:10:51 <felixfontein> #topic Ansible 4.0.0 schedule
19:10:52 <abadger1999> https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
19:10:59 <felixfontein> #info https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
19:10:59 <abadger1999> https://github.com/ansible/ansible/pull/73465
19:11:00 <github-linkbot> https://github.com/ansible/ansible/pull/73465 | open, created 2021-02-03T18:57:04Z by abadger: [WIP] Ansible 4 roadmap [WIP,affects_2.11,docs,needs_triage,support:core]
19:11:15 <felixfontein> #info Roadmap: https://github.com/ansible/ansible/pull/73465
19:11:18 <abadger1999> I've put together a schedule for Ansible-4.
19:11:58 <abadger1999> Compared to the ansible-3 schedule, it has more pre-releases and a few added deadlines.
19:12:38 <abadger1999> I start alpha releases at the beginning of March because ansible-core-2.11 is going to start making beta releases then.
19:12:38 <felixfontein> that's because there's ansible-core 2.11 :)
19:13:04 <abadger1999> The hope is that people will test the combination and point out any issues they see with enough time to make fixes to ansible-core.
19:13:39 <felixfontein> ETA for ansible-core 2.11.0 is 2021-04-26
19:14:02 <felixfontein> (the hackmd link includes both core and ansible dates)
19:14:12 <abadger1999> Our beta would coincide with ansible-core-2.11.0 final being released.
19:14:21 <abadger1999> 2021-04-27 - ansible-4.0.0 beta1
19:14:43 <gundalow> jimi|ansible: sivel nitzmahone FYI `ansible==4.0.0` proposed release schedule https://github.com/ansible/ansible/pull/73465
19:14:44 <abadger1999> And final would come on 2021-05-18 - ansible-4.0.0 release
19:14:53 <abadger1999> relrod: ^
19:15:32 <abadger1999> For collection owners, reviewers, and the people who regularly vote at this meeting, there are some new deadlines
19:15:41 <abadger1999> 2021-04-13 - last day for new collections to be submitted for inclusion in ansible-4.
19:15:53 <abadger1999> 2021-04-14 - Community IRC Meeting topic: list any new collection reviews which block release. list any backwards incompatible collection releases that beta1 should try to accommodate.
19:16:03 <abadger1999> 2021-04-21 - Community IRC Meeting topic: Decide what contingencies to activate for any blockers that do not meet the deadline.
19:16:19 <abadger1999> 2021-04-26 - last day for new collections to be approved for inclusion in ansible-4
19:17:21 <dmsimard> makes sense to me and I like the distinct date for applications and approvals
19:17:38 <abadger1999> 2021-04-26 is also the last day on the schedule for backwards incompatible collection releases to be made (but in actuality, I will pick up[ ones that are made early enough in the day on the 27th.  But collection owners should not count on that unless they speak to me directly about their needs)
19:18:32 <abadger1999> That's the executive summary of what's in the new schedule.
19:18:44 <felixfontein> I think it makes sense :)
19:19:35 <jillr> +1
19:19:57 <felixfontein> does anyone have questions about the schedule, or requests for changes?
19:20:30 <cybette> ding! 10min in topic - Ansible 4 schedule, 20min in meeting
19:20:45 <abadger1999> One open question which I think needs to be thought about separately is whether we want to change the review rpcoes in any way for 4.0 (do not prioritize first-come-first served, trying to get collection owners to review other collections, etc).  I'm going to wait until we can talk about how we think ansible-3.0's reviews went before bringing that up, though.
19:21:11 <abadger1999> If there aren't questions or suggestions, then I guess we should vote :-)
19:21:50 <felixfontein> +1 for discussing the review process later
19:22:26 <abadger1999> Cool :-)
19:22:47 <felixfontein> (I think it needs a bit more preparation :) )
19:22:49 <gundalow> I'm OK with later assuming that means we can't move the inclusion dates (much)
19:22:51 <abadger1999> VOTE: Approve the Ansible-4.0 schedule: PR for docs.a.c: https://github.com/ansible/ansible/pull/73465   document with  background info: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw
19:23:04 <felixfontein> +1
19:23:07 <gundalow> +1
19:23:08 <dericcrago> +1
19:23:11 <acozine> +1
19:23:12 <tadeboro> +1
19:23:12 <abadger1999> +1
19:23:20 <jillr> +1
19:23:38 <samccann> +1
19:23:49 <gundalow> maybe the background could be moved to docs.ansible.com/community once we have that setup? I assume it will be similar for future realeasesreleases?
19:24:00 <cybette> +1
19:24:04 <gundalow> (how do i type?)
19:24:36 <abadger1999> gundalow: Yeah.  (It will be a little different but having a record of rationale will be good for designing future schedules)
19:24:56 <abadger1999> Right now, the hackmd is backed by a git repo so there's history if we need it.
19:25:39 <felixfontein> #agreed We approved the Ansible-4.0 schedule: PR for docs.a.c: https://github.com/ansible/ansible/pull/73465 (document with background info: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw)
19:26:04 <felixfontein> #topic community.network: who wants to take over maintenance / releasing?
19:26:24 <felixfontein> is anyone interested in doing this?
19:27:14 <gundalow> I volunteer dericcrago and dmsimard :)
19:27:18 <felixfontein> lol
19:27:18 <samccann> is it worth describing what it means to take over?
19:27:24 <gundalow> samccann: too late!
19:27:30 <gundalow> Though, yes, that would be useful
19:27:31 <samccann> heh unless someone's volunteer-ed
19:27:51 <gundalow> Unless we have lots of other stuff to get through today
19:27:56 <felixfontein> the main tasks are making sure that CI doesn't break, merging PRs (if the bot isn't around) and deciding what should be backported, and doing releases
19:28:10 <abadger1999> Is there anyone involved in writing code for that collection that would like to take over?
19:28:29 <felixfontein> the main problem is that there are some community contributions, but almost nobody reviews them, so most things do not get merged
19:28:44 <dmsimard> I'd be happy to help with maintenance/releasing in general but I wouldn't be comfortable reviewing network code stuff
19:29:23 <dmsimard> we could bring it up at a network working group meeting
19:29:33 <gundalow> dmsimard: yup, sounds wise
19:29:34 <abadger1999> felixfontein: Are there any repeat PR-submitters?
19:29:39 <dericcrago> you kind of need someone else with the network gear to kind of manually test PRs if there isn't a network device testing framework in place, right?
19:29:44 <jillr> it looks like most of the open PRs are from the same person, perhaps we could reach out to them?
19:30:00 <dericcrago> or is setting up the proper testing what we're talking about?
19:30:13 <felixfontein> abadger1999: there are some, for some existing modules (the ones jillr is mentioning), but most not I think
19:30:42 <abadger1999> Okay.
19:31:12 <dmsimard> let me take an action to chat with the network group and we can see what's next
19:31:24 <felixfontein> dericcrago: having some network knowledge to be able to judge whether a change could be ok should already help a lot, I guess. testing would be great, but I think it would also be ok to merge things without testing them yourself.
19:31:35 <dmsimard> #action dmsimard to talk about community.network maintenance at the next network working group meeting
19:31:38 <felixfontein> dericcrago: I don't have much network experience, so I'm the wrong person for that :)
19:31:55 <felixfontein> cool!
19:31:57 <felixfontein> thanks, dmsimard!
19:31:58 <abadger1999> It's sounding like we need to start getting those people more actively involved.  Maybe set up a weekly meeting that they can attend and giving them permission to merge commits with the understanding that they'll also start reviewing and merging other people's commits.
19:32:07 <abadger1999> Cool, thanks dmsimard
19:32:27 <dmsimard> oh bummer, they just had their meeting earlier today
19:32:34 <felixfontein> abadger1999: it would probably also be easier once the bot is running
19:32:35 * dmsimard puts it on agenda
19:33:31 <felixfontein> gundalow: should we talk about the Python version policy, even though o. isn't around?
19:33:52 <gundalow> felixfontein: yup
19:34:14 <gundalow> abadger1999: Would you be able to drive this given o isn't around?
19:34:21 <abadger1999> Sure.
19:34:30 <abadger1999> But I haven't read his proposal yet.
19:35:00 <felixfontein> #topic Proposal for Python version support for collections (https://github.com/ansible-collections/overview/pull/151)
19:35:01 <github-linkbot> 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:35:09 <felixfontein> I guess we spend the first 1-2 minutes all reading the proposal :)
19:35:52 <felixfontein> I think the idea is to see whether it (and possible changes) are what we want, and give feedback to ompragash so he can adjust the proposal so we can vote on it maybe next week
19:36:48 <abadger1999> So, as background: ansible/ansible in 2.9 and earlier had a policy that plugins and modules had to run on certain python versions unless they depended on a library that wasn't available on those versions.
19:38:57 <cyberpear> proposal LGTM 2.6+ and 3.5+
19:38:58 <abadger1999> That allowed end users to know that when they ran ansible, (1) the vast majority of the controller's plugins would run on a distro that had that python version and (2) the vast majority of modules could be used to manage a distro that had that python version.
19:39:22 <abadger1999> I think that's a worthwhile goal.
19:39:40 <abadger1999> And we should try to maintain it.
19:40:28 <cybette> ding! 5min in Python version proposal, 40min in meeting
19:40:36 <tadeboro> I do not like the current proposal because it requires too much. I would rather see if collections are required to support python versions that we know are used in stable distros. They can still support really old versions like 2.6 if the maintainers are willing to put in the work required, but I would not force everyone into this.
19:41:36 <acozine> what is driving the proposed change? Is there a particular collection that has trouble with the current rules? Or is it just a general "we should be less restrictive"? Or something else?
19:41:42 <tadeboro> FOr python packages I help maintain, we usually support 2.7, 3.6-3.9.
19:41:47 <abadger1999> tadeboro: I am not quite sure what you mean by this: " rather see if collections are required to support python versions that we know are used in stable distros. "
19:42:07 <abadger1999> acozine: yeah, ansible.utils objected tot his.
19:42:11 <felixfontein> isn't RHEL6 kind of stable?
19:42:33 <acozine> The current guidelines give collections the ability to drop support for specific python versions, don't they? What is the blocker for ansible.utils?
19:42:49 <abadger1999> Yeah, for managing, I think it would be a good idea to continue to support managing RHEL6.  So I think modules should have python-2.6 as a lower bound.
19:42:57 <tadeboro> ansible.utils only wants to support Python 3.8
19:42:59 <felixfontein> acozine: there isn't, but they thought out loud about not supporting any Python version except 3.8 (and maybe 3.9)
19:43:08 <felixfontein> which is a bit... little
19:43:18 <abadger1999> acozine: The current guidelines do not mention it.  But the ansible/ansible guideliens from 2.9 and before would have required them to support more.
19:44:13 <felixfontein> I can understand if collections want to drop Python 2.6 support, or 3.5 support; 2.7 is more tricky, since 2.7 is still wide-spread, and dropping 3.6+ support requires Very Good Arguments IMO
19:44:19 <abadger1999> acozine: And we haven't really discussed here whether those guidelines apply to the colledctions we're allowing in or not (I tend to think they do... but we haven't been explicit).
19:44:40 <tadeboro> Also, let us take the sensu.sensu_go collection I help main as an example. Supporting Python 2.6 in that collection makes no sense since 99% of the time, modules run on localhost.
19:45:26 <felixfontein> (Python 3.5 has funny quirks that even Python 2.6 no longer has)
19:45:39 <abadger1999> <nod>
19:46:53 <acozine> I'm confused. Current text of https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#ci-testing says `Collections can choose to skip certain Python versions that they explicitly do not support; this needs to be documented in README.md and in every module and plugin (hint: use a docs fragment).`
19:46:58 <jillr> I think it's asking a lot to require collections in the community distro to support 2.6 or 3.5.  if they want to get certified for automation hub and RHEL6 that's a different story but not what we're doing here.
19:47:03 <abadger1999> I think there's several axes here: (1)  controllerside versus remote side. (2) are modules that mostly run on localhost controllerside or remote side? (3) minimum versions of python2 and python3? (4) When should these versions be updated?
19:47:13 <tadeboro> So the way I see things, I would say certain things are a must (like 2.7, 3.6-) while others are nice to have.
19:47:39 <dmsimard> 2.7 will be increasingly harder to support and maintain
19:47:47 <felixfontein> tadeboro: always under the assumption that the libraries that are used actually support 2.7 and 3.6 :)
19:48:00 <gundalow> Controller vs remote-node is a good point
19:48:20 <felixfontein> tadeboro: https://github.com/ansible-collections/ansible-inclusion/discussions/13 for example requires Python 3.6+, because the SDK they use is 3.6+ only
19:48:21 <cyberpear> agreed that for collections that usually run only on "localhost" (such as cloud modules), the requirement should be more lax
19:48:55 <felixfontein> don't forget about ansible-pull, where localhost might be a remote machine
19:49:03 <jillr> +1 what cyberpear said
19:49:23 <cyberpear> felixfontein: yes, but ansible-pull only works on hosts where ansible controller works
19:49:30 <abadger1999> cyberpear: I tend to think that's logical although I do wonder what "usually run on" should be defined as.
19:49:40 <felixfontein> cyberpear: yes, but that only removes 2.6 from the list :)
19:49:58 <cyberpear> maybe "manages some other resource that's actually not on the 'managed node'"
19:50:13 <abadger1999> cyberpear: for instance, if a site requires that configuring certain hosts has to be done from a "bastion host", then a module that can run remotely is an imprtant feature.
19:50:21 <cybette> ding! 15min in Python version proposal, 50min in meeting
19:50:39 <tadeboro> Most new collections we revieved for 3.0.0 were web API consumers. And those usually run on control node.
19:50:39 <cyberpear> agreed.  supporting bastions is good.
19:51:15 <felixfontein> does anyone disagree with that collections can drop support for Python 2.6 and 3.5? if no, we could vote on that, then we already have reduced the set of versions to continue discussing :)
19:51:50 <felixfontein> tadeboro: always depends on where that web API is reachable
19:52:15 <tadeboro> felixfontein: This is why I operate with 99% and usually ;)
19:52:22 <felixfontein> hehe :)
19:53:03 <tadeboro> I would vote for making 2.6 and 3.5 support optional.
19:53:18 <dmsimard> 2.6 is long, long EOL
19:53:37 <jillr> I am highly in favor of making 2.6 and 3.5 optional
19:54:03 <felixfontein> VOTE: Collections do not need to support Python 2.6 and Python 3.5 if they chose not to. This must be well documented though (for every plugin/module, and in the collection README).
19:54:07 <felixfontein> #chair
19:54:07 <zodbot> Current chairs: abadger1999 acozine cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro
19:54:13 <dmsimard> +1
19:54:16 <samccann> +1
19:54:17 <jillr> +1
19:54:21 <abadger1999> acozine: So, here's what we have right now: https://docs.ansible.com/ansible/latest/dev_guide/developing_python_3.html#minimum-version-of-python-3-x-and-python-2-x    That may be included or may not be included in our policies because "they always have been" but we didn't explicitly talk about it now.  Reviewers can certainly decide that they won't approve a review and even veto a review based on that because of: "
19:54:21 <abadger1999> Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee. "
19:54:22 <gundalow> +1
19:54:28 <felixfontein> (the documentation part is what we wrote somewhere already, I think)
19:54:30 <felixfontein> +1
19:54:34 <cidrblock> +1
19:54:34 <abadger1999> -1
19:54:39 <gundalow> I'd really like `meta/runtime.yml` to define the supported Python version
19:54:42 <gundalow> #chair cidrblock
19:54:42 <zodbot> Current chairs: abadger1999 acozine cidrblock cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro
19:54:47 <tadeboro> +1
19:54:49 <abadger1999> I would be okay with that controllerside.
19:55:05 <cybette> +1
19:55:06 <cyberpear> +1, but I'd like to strongly suggest not breaking 2.6 for existing modules that work there
19:55:07 <abadger1999> But if that becomes widespreaqd, then module-sie, you would no longer be able to manage rhel6.
19:55:12 <felixfontein> I think we should still recommend collections to also support 2.6 and 3.5, but we shouldn't require it
19:55:27 <abadger1999> Therefore, I don't think a broad rule like that is a good idea.
19:55:29 <felixfontein> cyberpear: yes, exactly. only for Very Good Reasons, not for "I'm lazy" ;)
19:55:41 <dmsimard> so rhel6 ships 2.6 ?
19:55:50 <abadger1999> If we enumerate the Very Good Reasons, I can be for it.
19:56:08 <cyberpear> dmsimard: yes, and there's 3+ years of ELS supported security patches remaining for it
19:56:35 <dericcrago> +1
19:56:37 <cidrblock> Was the vote for community modules or platform?
19:56:54 <felixfontein> cidrblock: the vote is for the Ansible community distribution
19:56:58 <abadger1999> cidrblock: The vote is for inclusion in the ansible package.
19:57:05 <cyberpear> (just last year, I had folks deploying new RHEL 6 boxes, for probably bad reasons)
19:57:10 <cidrblock> Ok, TY +1 again
19:57:12 <dmsimard> felixfontein: is "it's EOL" not a good enough reason ?
19:57:15 <felixfontein> cyberpear: why oh why?
19:57:19 <tadeboro> Maybe we should just clearly describe what dropping support for python 2.6 means. COmment like "cannot manage RHEL 6" ...
19:57:40 <abadger1999> cyberpear: Yep... which is why I think allowing everyone to drop python-2.6 support remote-side is a bad idea.
19:57:44 <dmsimard> I think we should be wary of placing the burden of maintenance of long EOL python versions onto the community
19:57:58 <jillr> dmsimard++
19:57:58 <zodbot> jillr: Karma for dmsimard changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:58:01 <dericcrago> are there similar ramifications when dropping 3.5?
19:58:06 <samccann> catching up w/ the  thread here - seems like yes, we should still recommend collections that work with RHEL 6.
19:58:22 <abadger1999> Even when RHEL6 hits its first EOL (ie: you must pay a special amount of money to get support), there will still be RHEL6.
19:58:22 <cyberpear> is 3.5 in some LTS release?
19:58:45 <felixfontein> I think we should formulate the policy so that 2.6 and 3.5 support can be dropped, but should be avoided
19:58:50 <abadger1999> (But I use the RHEL EOL date  as a convenient place to draw the line ;-)
19:58:52 <ikhan> We need a good and easy way to communicate to the collection how to select which version of python they should support and what not.  It is not easy to figure that out.
19:59:06 <tadeboro> Supporting python 2.6 is in my experience only feasible if you use things from ansible.* exclusivelly. Getting anthing else installed for that python version is a nighmare or a decade old.
19:59:13 <samccann> So we could word it as 'should' with the note someone above suggested that 'if you do not, then you can't work w/ RHEL 6 and other distros'  (assuming there's more than one)
19:59:33 <abadger1999> ikhan: right now: ". Modules are allowed to drop support for Python 2.6 when one of their dependent libraries requires a higher version of Python. This is not an invitation to add unnecessary dependent libraries in order to force your module to be usable only with a newer version of Python; "
19:59:36 <gundalow> #chair ikhan
19:59:36 <zodbot> Current chairs: abadger1999 acozine cidrblock cyberpear cybette dericcrago dmsimard felixfontein gundalow ikhan jillr lmodemal samccann tadeboro
19:59:38 <jillr> automation platform exists for the long term support RHEL6 customers - and has its own certification process
19:59:49 <jillr> I dont think we should extend that support burden to community collections
19:59:51 <abadger1999> With a big asterisk by it that we're not yet in agreement that that rule applies or not.
20:00:16 <felixfontein> I agree with jillr (and I think dmsimard also said that before). if we require 2.6 (and 3.5) support, we put a lot of extra burden on the community
20:00:42 <cybette> ding! 25min in Python version proposal, 1 hour in meeting
20:00:43 <acozine> is it an ongoing maintenance burden? or more of a barrier to entry for new collections?
20:00:51 <samccann> jillr: but we do have to be clear at the collection development phase, that there are drawbacks IF they want to work with  RHEL 6.  Maybe it goes in some certified collection detail somewhere?
20:00:51 <abadger1999> I think that to avoid being simply an aggregation of collections we need to have some rules.
20:01:07 <dmsimard> acozine: it means you need to test for it and write code that is compatible from 2.6 up until 3.9 or whatever
20:01:08 <felixfontein> some community collections (like community.general, community.crypto, ...) will always try to support it on a best-effort basis, but I don't think we should force community to support 2.6
20:01:11 <jillr> purely as a python developer, if I had a collection I wanted to submit and saw 2.6 and 2.7 required support I would probably just not do so and distribute purely on galaxy
20:01:27 <abadger1999> We could be explicit that ansible no longer guarantees that it can manage RHEL6.
20:01:28 <acozine> dmsimard: yes, but don't most existing modules already do that?
20:01:35 <felixfontein> also the people who pay a lot of money for RHEL6 extended support could hire someone to maintain Python 2.6 support in collections if they care that much :)
20:01:42 <jillr> working for a vendor that wants to extend enterprise support is different
20:01:44 <abadger1999> although that's a little odd since ansible-base does say that it can be used to manage rhel6.
20:01:44 <acozine> felixfontein: heh
20:02:03 <dericcrago> cyberpear - I know of at least ubuntu xenial shipping with 3.5
20:02:24 <felixfontein> dericcrago: it also comes with Python 2.7 by default, doesn't it?
20:02:25 <cyberpear> RHEL 6 ELS security support is thru June 30, 2024, fwiw.  ELS hasn't been announced for RHEL 7 yet
20:02:25 <jillr> samccann: absolutely, we should document what it means to collection maintainers
20:02:33 <abadger1999> yeah, 2.6 was because of rhel6 and 3.5 was because of ubuntu xenial.
20:03:08 <dmsimard> acozine: it's fine if maintainers want to do that work, I'm saying it is not reasonable to expect that of everyone
20:03:17 <dericcrago> felixfontein - that's correct and a good point
20:03:47 <felixfontein> dericcrago: so there's no real need to support 3.5 if you support 2.7
20:04:03 <dericcrago> felixfontein - agreed
20:04:14 <felixfontein> ok. for the current vote, does anyone wants to change their vote?
20:04:22 <cyberpear> just tested: `apt install python` on Xenial brings 2.7
20:04:33 <felixfontein> reminder: VOTE: Collections do not need to support Python 2.6 and Python 3.5 if they chose not to. This must be well documented though (for every plugin/module, and in the collection README).
20:04:38 <felixfontein> (in case someone forgot :) )
20:04:43 <tadeboro> felixfontein: IIRC, xenila does not come with python 2.7 out of the box. You need to manually install in when using official images.
20:04:56 <felixfontein> tadeboro: does it come with 3.5 out of the box?
20:04:57 * tadeboro still has some scars because of this fact ...
20:05:08 <abadger1999> felixfontein: Could we add that it must be a major version bump for a collection to drop support?
20:05:10 <tadeboro> felixfontein: Yes, 3.5 is default python on xenial.
20:05:30 <cyberpear> 3.5.2, apparently
20:05:35 <dmsimard> for the record: py2.6 is EOL since October 2013 if I read correctly, 2.7 is EOL since January 2020
20:05:38 <felixfontein> abadger1999: I would assume that's clear, since it is a breaking change in the API :)
20:05:42 <jillr> +1 major version bump when changing supported pythons
20:05:48 <dericcrago> I'm checking a new xenial server install now, the docker container doesn't come with either
20:05:51 <abadger1999> dmsimard: Upstream EOL is a lot different than downstream EOL.
20:06:10 * gundalow -> afk
20:06:19 <felixfontein> #agreed Collections do not need to support Python 2.6 and Python 3.5 if they chose not to. This must be well documented though (for every plugin/module, and in the collection README). (many +1, one -1)
20:06:24 <dmsimard> abadger1999: indeed
20:06:24 <cyberpear> major version bump when changing supported versions in existing modules; new additions requiring newer python should be fine, IMO
20:06:58 <abadger1999> users mostly get their python from their vendor, not from python.org/download.  So if Red Hat continues to support RHEL6 with python2.6, that's what users of rhel6 will be expecting.
20:07:11 <felixfontein> should we add something like 'We recommend that collections try to support 2.6 and 3.5 as well. Also note that dropping support for a Python version for an existing module/plugin is a breaking change, and thus requires a major release.'
20:07:45 <samccann> with a note that says dropping these means not working with some LTS distros
20:08:16 <dericcrago> can confirm (along with everyone else) xenial comes with only Python 3.5.2 (although Python 2.7.12) can be installed
20:08:23 <tadeboro> I would rather document the reasons for still supporting older python versions.
20:08:24 <felixfontein> should we add something like 'We recommend that collections try to support 2.6 and 3.5 as well. Not supporting Python 2.6 means that you are dropping support for RHEL6, which has extended support until 2024. Also note that dropping support for a Python version for an existing module/plugin is a breaking change, and thus requires a major release.'
20:08:44 <dmsimard> dericcrago: yep, I remember needing to drop f-strings (from 3.6) to support 3.5 because of xenial
20:09:04 <jillr> felixfontein: +1 (and a similar note about xenial)
20:09:09 <abadger1999> <nod>  And dropping support for python-3.5 means dropping out-of-the-box support for Ubuntu Xenial.
20:09:16 <tadeboro> +1
20:09:54 <felixfontein> should we add something like 'We recommend that collections try to support 2.6 and 3.5 as well. Not supporting Python 2.6 means that you are dropping support for RHEL6, which has extended support until 2024. Not supporting Python 3.5 means that Python 2.7 has to be installed on Ubuntu Xenial (16.04), and that you have to support Python 2.7. Also note that dropping support for a Python
20:10:00 <felixfontein> version for an existing module/plugin is a breaking change, and thus requires a major release.'
20:10:16 <felixfontein> like ^ ?
20:10:18 <cybette> ding! 35min in Python version proposal, 1:10 into meeting
20:10:38 <abadger1999> We'll probably want the release announcement and documentation for ansible-4.0 to say something about support for  RHEL6 and Xenial being second class.
20:11:18 <dericcrago> you could say that xenial only has ~2 more months or ~3 more years of support /shrug
20:11:18 <jillr> +1
20:11:20 <acozine> abadger1999: maybe "we're phasing out support for RHEL6 and Xenial in the community distribution"
20:11:25 <felixfontein> I guess they are already 2nd class right now, from a practical point of view
20:11:34 <abadger1999> felixfontein: +1
20:11:40 <acozine> heh, yep, but it's kind of a loaded phrase
20:11:57 <tadeboro> +1 (for what felixfontein proposed) and +1 (for announcement suggested by abadger1999)
20:11:59 <jillr> "Please stop deploying old distros" ;)
20:12:25 <abadger1999> felixfontein: ehhh... For the most part the sanity tests have kept people maintaining compat.  Once we make this rule, I think the floodgates will open.
20:12:37 <felixfontein> I wouldn't use the words "second class" though :)
20:12:46 <samccann> I'd be uncomfortable with stating 'we are phasing out support for RHEL6' without approval from The Powers That Be
20:12:52 <acozine> I have a meeting at the half-hour that I need to prep for - I'm happy to wordsmith any PRs that come out of this discussion if desired.
20:13:03 <abadger1999> jillr: It's actually "Please port your mission critical code that you **think** Just Works(TM) away from old distros"
20:13:08 <felixfontein> abadger1999: right now you have to use ignore.txt entries anyway, so the floodgate is in theory already open
20:13:25 <acozine> samccann: even "in the community distribution"? isn't that what upstream stuff is for? Experimentation and leading the way to the future?
20:13:42 <jillr> abadger1999: "Forklift it into a docker container and redeploy it on a modern distro"
20:14:00 <abadger1999> felixfontein: yeah, but with the docs.a.c rule, we should be questioning people anytime we see that.
20:14:26 <samccann> acozine: yes, even in community distro. I'm fine with saying collection owners 'should' do this and that and if they dont it won't work with RHEL6 etc.  But not saying we are phasing RHEL6 support out. That sounds like wording that needs some higher approval
20:14:26 <acozine> #unchair acozine
20:14:26 <zodbot> Current chairs: abadger1999 cidrblock cyberpear cybette dericcrago dmsimard felixfontein gundalow ikhan jillr lmodemal samccann tadeboro
20:14:30 <abadger1999> jillr: heh.  But then I won't be able to use ansible to build and manage that container ;-)
20:14:55 <jillr> :)
20:15:00 <tadeboro> abadger1999: From my experience, right now makking colelction pass sanity test on 2.6 is easy. Creating an integration test is almost impossible. I am not sure if I know how should I even get an access to distro with python 2.6
20:15:02 <abadger1999> dehaan's phrase for using containers like that  was "ghetto virtual machines"
20:15:07 <felixfontein> VOTE: Add 'We recommend that collections try to support 2.6 and 3.5 as well. Not supporting Python 2.6 means that you are dropping support for RHEL6, which has extended support until 2024. Also note that dropping support for a Python version for an existing module/plugin is a breaking change, and thus requires a major release.'
20:15:12 <felixfontein> #chair
20:15:12 <zodbot> Current chairs: abadger1999 cidrblock cyberpear cybette dericcrago dmsimard felixfontein gundalow ikhan jillr lmodemal samccann tadeboro
20:15:18 <felixfontein> I think that part was uncontroversial
20:15:38 <felixfontein> so let's see if we want to approve it, before continuing discussing the other stuff :)
20:15:49 <samccann> we voting on that w/o the tidbit on xenial?
20:16:02 <felixfontein> oh
20:16:06 <felixfontein> oops
20:16:07 <felixfontein> sorry, no
20:16:27 <felixfontein> VOTE: Add 'We recommend that collections try to support 2.6 and 3.5 as well. Not supporting Python 2.6 means that you are dropping support for RHEL6, which has extended support until 2024. Not supporting Python 3.5 means that Python 2.7 has to be installed on Ubuntu Xenial (16.04), and that you have to support Python 2.7. Also note that dropping support for a Python version for an existing
20:16:33 <felixfontein> module/plugin is a breaking change, and thus requires a major release.'
20:16:36 <felixfontein> that's the one
20:16:45 <felixfontein> (they were right next to each other in my line buffer, and didn't differ in the part I could see...)
20:16:53 <jillr> +1
20:17:00 <dmsimard> lgtm +1
20:17:08 <tadeboro> +1
20:17:21 * lmodemal Hard stop. Leaving to walk nanny out.
20:17:25 <abadger1999> -1 (but that's okay.  I think as far as it goes, it is as good as it can be)
20:17:36 <felixfontein> +1
20:18:02 <samccann> 0  (when abadger goes negative, i just worry I'm missing something)
20:18:25 <abadger1999> nah, it's a foundational difference of opinion.
20:19:09 <samccann> yeah and until I understand that difference, I'll stay neutral so as not to sway the vote either way.
20:19:19 <felixfontein> abadger1999: if you're worrying, I'm still requiring every PR in community.general to pass the 2.6 and 3.5 compile tests, even if contributors sometimes complain :)
20:19:27 <bcoca> i would not that not just rhel6 but other distros released at same time (mostly derivatives)
20:19:58 <abadger1999> felixfontein: Hmm... does that kind of defeat the purpose?
20:20:00 <felixfontein> bcoca: I guess once we have the basic text, we can add some more names to the list
20:20:18 <cybette> ding! 45min in Python version proposal, 1:20 into meeting
20:20:23 <felixfontein> abadger1999: I don't think so, since every collection can still decide whether they want to support 2.6 and 3.5 or not
20:20:36 <abadger1999> Maybe insteadof recommends, we'd need to say SHOULD
20:20:48 <abadger1999> oh..
20:20:53 <abadger1999> I guess I'm not understanding
20:21:06 <abadger1999> Oh!
20:21:09 <felixfontein> anyone else has a vote for the above vote?
20:21:10 <abadger1999> "community.general"
20:21:18 <abadger1999> That's what I missed in what you said at first
20:21:25 <felixfontein> abadger1999: yes, that one :) (also for the other community.* collections I'm working on)
20:21:47 <felixfontein> #agreed Add 'We recommend that collections try to support 2.6 and 3.5 as well. Not supporting Python 2.6 means that you are dropping support for RHEL6, which has extended support until 2024. Not supporting Python 3.5 means that Python 2.7 has to be installed on Ubuntu Xenial (16.04), and that you have to support Python 2.7. Also note that dropping support for a Python version for an
20:21:53 <felixfontein> existing module/plugin is a breaking change, and thus requires a major release.'
20:22:06 <felixfontein> should we vote on changing the 'recommend' to 'SHOULD', i.e. 'Collections SHOULD try to support 2.6 and 3.5 as well.'?
20:22:19 <dericcrago> tadeboro - you're in luck ;) $ docker container run -it --rm ubuntu:lucid python --version
20:22:19 <dericcrago> Python 2.6.5
20:22:22 <felixfontein> (is that what you suggested abadger1999?)
20:22:38 <abadger1999> My feeling would be recommends is optional but we recommend it.  SHOULD is... reviewers discretion.
20:22:47 <abadger1999> I don't care which you all want.
20:22:54 <felixfontein> if I need Python 2.6, I always use the ansible-test default container ;)
20:23:10 <felixfontein> ok let's have a quick vote and see whether anyone cares :)
20:23:26 <felixfontein> VOTE: Change the 'recommend' to 'SHOULD' in the above, i.e. 'Collections SHOULD try to support 2.6 and 3.5 as well.'
20:23:29 <felixfontein> #chair
20:23:29 <zodbot> Current chairs: abadger1999 cidrblock cyberpear cybette dericcrago dmsimard felixfontein gundalow ikhan jillr lmodemal samccann tadeboro
20:23:36 <abadger1999> so only vote pon the suggestion if you want reviewers to be able to block the review if the maintainer does not agree with tthe reviewer's request to support 2.6 or 3.5.
20:24:33 <abadger1999> +0
20:24:38 <dmsimard> either works for me, +1
20:24:50 <felixfontein> or vote -1 if you explicitly don't want this to be reviewer's discretion
20:24:59 <abadger1999> Right :-)
20:25:21 <abadger1999> reviewer's discretion probably leadsdto this coming back here at some point in the future.
20:25:25 <jillr> -1  (but I don't feel strongly enough to block it if a majority disagrees)
20:25:51 <samccann> so to be sure I understand... if I created a collection called `community.rhel6` and it had only python 3.6, then with the new change, y'all could reject my collection... but with the existing text, you could not reject it?
20:26:14 <dericcrago> should and recommend sound the same to me in that it wouldn't block me from submitting something that didn't support python 2.6 or 3.5
20:26:23 <tadeboro> +1 (I do not care much, I will be PITA if I review a module that should support 2.6 or 3.5 in both cases).
20:26:33 <samccann> heh
20:27:11 <bcoca> fyi, many collections already dont suport 2.x due to relying on libraries that alraedy dont support it cloud and networking being prime examples
20:27:15 <felixfontein> samccann: I think so, though we could always find other reasons to not accept a collection :)
20:27:20 <abadger1999> Like a reviewer might say "I consider a chattr module to be a fundamental building block of managing a linux system so for me, it's a must that this module supports python2.6"  And the collection maintainersays "I don't believe that being a fundamental module for managing a linux system should mean we are required to support python-2.6".  Then it would come back here to be resolved.
20:27:50 <jillr> if we were talking about changing c.general's reqs I would feel differently, but I really don't think we should be so restrictive on brand new collections that no one is already using/expecting to be supported in a given environment
20:27:56 <bcoca> if it were fundamental it would be in core or ansible.* collections
20:27:57 <abadger1999> samccann: That's how I'd like to differentiate, yeah.
20:28:38 <felixfontein> bcoca: ansible.utils was thinking out loudly about only supporting 3.8 at some point
20:28:47 <jillr> "to use this shiny new thing you must be on rhel7 or later" seems perfectly reasonable to me
20:28:56 <samccann> I'm +1 if SHOULD makes it more obvious that we can reject a collection if we feel it needs these lower phython versions to be a usable collection.
20:29:48 <tadeboro> jillr: If feels strange to read "rhel7" and "shiny new thing" in the same sentence ;)
20:29:56 <felixfontein> I think SHOULD is ok since if one reviewer really says not supporting 2.6 is not ok for this collection, other reviewers can still disagree. and if nobody disagrees, I guess it's ok if it is rejected anyway :)
20:29:57 <jillr> tadeboro: you and me both!  :)
20:30:13 <bcoca> felixfontein:  i have issue with ansible.utils itself existing .. but that is other convo
20:30:19 * jillr misses writing py3-only code
20:30:35 <cybette> Ding! 55min in Python version proposal, 1:30 into meeting!
20:31:04 <felixfontein> ok, so we have 1 x -1, 1 x +0, 2 x +1 so far
20:31:31 <felixfontein> ah wait, 3 x +1
20:31:55 <felixfontein> +1
20:31:56 <felixfontein> ok
20:32:04 <felixfontein> I think now it is more clear :)
20:32:21 <felixfontein> #agreed Change the 'recommend' to 'SHOULD' in the above, i.e. 'Collections SHOULD try to support 2.6 and 3.5 as well.' (1 x -1, 1 x +0, 4 x +1)
20:33:01 <felixfontein> do you want to continue discussing this topic? we still have 2.7, 3.6, 3.7 to talk about ;)
20:33:32 <felixfontein> we could require that these are supported (and 3.8 and 3.9), with the possible exception that a library used does not support them
20:33:37 <abadger1999> I think it would be better to discuss other things (we're not going to get to a final draft of this one today)
20:33:40 <felixfontein> that would make it clear what we accept and what we do not accept
20:33:46 <felixfontein> ok, good
20:34:02 <abadger1999> Yeah, that would be a good proposal for next time
20:34:05 <felixfontein> #topic Require that collection releases are tagged in the git repo
20:34:15 <felixfontein> I think this is a 'easy' one
20:35:08 <felixfontein> this is already what most collections are doing, I think
20:35:22 <felixfontein> (especially the ones releasing with zuul, they have no other choice)
20:35:40 <jillr> does this mean we'd require that collections are released from a tag rather than a branch?
20:35:57 <abadger1999> I don't think so.
20:36:01 <felixfontein> jillr: no, only that the commit that ends up in the release is also tagged
20:36:14 <tadeboro> No, just the commit that was used to release the artifact should be tagged.
20:36:28 <jillr> ah ok, thx
20:37:31 <felixfontein> (hmm I was looking at a collection repo that didn't use tags when I wrote this on the agenda, but I forgot which one)
20:38:01 <tadeboro> felixfontein: infoblox?
20:38:38 <abadger1999> I am hesitant over every rule that is a "How the collection is made" rather than "What the collection is delivering" but our rules do contain a large amount of "How" so I don't have concerns with this in and of itself.
20:38:41 <felixfontein> tadeboro: I thought so first, but they have tags
20:38:52 <tadeboro> They have them now ;)
20:39:23 <felixfontein> tadeboro: ah indeed (https://github.com/infobloxopen/infoblox-ansible/tags). but I think they were already there three days ago when I wrote that comment :)
20:40:28 <felixfontein> abadger1999: that's true, also I think until now we don't even require a version control system at all
20:40:33 <jillr> I might prefer this as a should, but I'm ok with it as a must and we can bring it here if a collection has a specific concern
20:41:55 <tadeboro> I would enforce a tag because galayx artifacts might not have all the pieces that are in the repo. So I like having a fixed point to look at when digging through the repo at certain version.
20:42:01 <felixfontein> jillr: I'm wondering all the time whether there is a reason why this doesn't make sense to someone - though just because I can't think of one, doesn't mean there isn't...
20:42:31 * cyberpear steps out to another meeting
20:42:48 <felixfontein> tadeboro: we could also require a tag, or something else that marks the exact state of the sources that were used to build the collection artifact
20:42:50 <jillr> felixfontein: if they're using a private vcs that we can't see anyway?
20:43:12 <felixfontein> jillr: or none at all ;)
20:43:16 <jillr> does rcs support tagging?  ;)
20:43:24 <felixfontein> no idea....
20:43:35 <felixfontein> SVN does, by copying ;)
20:43:48 <jillr> I'm pretty sure bzr does
20:44:23 <felixfontein> I'm wondering whether we should actually accept a collection with a private repo (or without a repo)
20:44:31 <abadger1999> rcs is not whole tree.  Each file has a distinct version
20:44:48 <abadger1999> svn and bzr do support tagging
20:44:55 <cyberpear> definitely want public SCM, IMO
20:45:15 <cyberpear> "throw it over the wall" isn't FLOSS spirit, even if technically Open Source
20:45:23 <cybette> ding! 11min in Require collection releases to be tagged, 1:45 into meeting
20:45:30 <felixfontein> cyberpear: exactly
20:45:53 <jillr> ok so, require tagging and if that doesn't work (because not public or using my_collection_1.2.3.zip.bak for releases) it goes to a vote here?
20:46:25 <felixfontein> or a bit broader: require public SCM and tagging, and if not, it's voted on?
20:47:47 <felixfontein> there are collections in Ansible which accept no outside contributions, but at least they have a public repo so it's possible to see what happened over time. I think that should be something we can expect from collections included in Ansible
20:48:11 <felixfontein> one can also download several collection artifacts and diff between them, but that's... horrible :)
20:48:12 <jillr> for the sake of argument, are we ok if that public repo is a mirror of a private repo?
20:48:33 <tadeboro> Since we are talking community here and already expect collections to describe how one can contribute, I would say that the repo must be public.
20:48:34 <jillr> ^for the case where something doesn't take contributions, for example
20:48:49 <felixfontein> jillr: would be ok for me. I don't think it's a great idea, but at least it's possible to see what is (and was) going on
20:49:04 <tadeboro> And I would be OK with mirror/read-only repo.
20:49:35 * samccann needs to drop
20:49:38 <jillr> that all sounds good to me
20:49:40 <samccann> #unchair samccann
20:49:40 <zodbot> Current chairs: abadger1999 cidrblock cyberpear cybette dericcrago dmsimard felixfontein gundalow ikhan jillr lmodemal tadeboro
20:49:55 <felixfontein> suggestion: 'Every collection must have a public SCM repository, and releases of the collection must be tagged in this repository.'
20:50:00 <jillr> (I'm also going to have to drop after this topic)
20:50:27 <felixfontein> should we vote on this? or has someone suggestions to change it?
20:50:40 <abadger1999> +1
20:50:41 <tadeboro> I say we vote.
20:50:47 <felixfontein> (I think we should really stop after this topic)
20:50:53 <felixfontein> VOTE: 'Every collection must have a public SCM repository, and releases of the collection must be tagged in this repository.'
20:50:56 <felixfontein> #chair
20:50:56 <zodbot> Current chairs: abadger1999 cidrblock cyberpear cybette dericcrago dmsimard felixfontein gundalow ikhan jillr lmodemal tadeboro
20:51:03 <tadeboro> +1
20:51:05 <jillr> +1
20:51:08 <felixfontein> +1
20:51:26 <cybette> +1
20:51:59 <dericcrago> +1
20:52:18 <felixfontein> #agreed 'Every collection must have a public SCM repository, and releases of the collection must be tagged in this repository.'
20:52:23 <felixfontein> #topic open floor
20:52:25 <felixfontein> ok
20:52:44 <felixfontein> anyone has something urgent for today? or is it time to get back to work / sleep / whatever? :)
20:53:51 <felixfontein> (I'm closing in two minutes, if nobody suggests something)
20:54:06 <dericcrago> closing sounds good to me felixfontein, thanks!
20:54:25 <felixfontein> :)
20:54:37 <tadeboro> I am leaving before anyone comes up with another topc ;)
20:54:42 <bcoca> well ...
20:54:44 <tadeboro> *topic
20:54:50 <jillr> shut it down - thanks felixfontein!
20:54:50 <felixfontein> I'm still hoping that at some point we have less tihngs to discuss so we can finish in one hour, or even less...
20:54:56 <felixfontein> #endmeeting