19:01:04 <felixfontein> #startmeeting Ansible Community Meeting
19:01:04 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
19:01:04 <zodbot> Meeting started Wed Feb 10 19:01:04 2021 UTC.
19:01:04 <zodbot> This meeting is logged and archived in a public location.
19:01:04 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:01:04 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:01:13 <dmsimard> o/
19:01:16 <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:01:17 <cybette> o/
19:01:20 <felixfontein> #chair dmsimard cybette
19:01:20 <zodbot> Current chairs: cybette dmsimard felixfontein
19:01:20 * dericcrago waves
19:01:21 <jillr> o/
19:01:24 <felixfontein> #chair dericcrago jillr
19:01:24 <zodbot> Current chairs: cybette dericcrago dmsimard felixfontein jillr
19:01:25 <tadeboro> o/
19:01:26 <briantist> hiya
19:01:27 <samccann> \o
19:01:27 <acozine> o/
19:01:31 <felixfontein> #chair tadeboro briantist samccann acozine
19:01:31 <zodbot> Current chairs: acozine briantist cybette dericcrago dmsimard felixfontein jillr samccann tadeboro
19:01:32 <lmodemal> Hi everyone!
19:01:34 <abadger1999> ola
19:01:37 <felixfontein> #chair lmodemal abadger1999
19:01:37 <zodbot> Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro
19:01:55 <felixfontein> great to see so many people around :)
19:02:44 <felixfontein> #topic Updates
19:02:44 <felixfontein> #info Ansible 2.10.7 and Ansible 3.0.0rc1 have been released, with a bunch of security fixes (potential information leaks)
19:02:45 * gundalow waves
19:02:47 <felixfontein> #info collection maintainers should look at the last few announcements in https://github.com/ansible-collections/overview/issues/45 regarding ansible-test / CI
19:02:50 <felixfontein> #chair gundalow
19:02:50 <zodbot> Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro
19:03:34 <dmsimard> #info A reminder that contributor summit is next month, make sure to read and add your topics to https://hackmd.io/uZDSLOOdS1Kx0xfZVIATmQ
19:04:00 <felixfontein> ah, we already fixed a date!
19:04:12 <felixfontein> (I must have missed that)
19:04:36 <dmsimard> it was in the last bullhorn (#19) :)
19:04:53 <cybette> felixfontein: we briefly mentioned it in bullhorn, and registration will start soon(tm) :)
19:05:00 <dmsimard> #link https://mailchi.mp/redhat/the-bullhorn-19
19:05:14 <felixfontein> ah!
19:06:24 <dmsimard> any other updates ?
19:06:58 <gundalow> yup,
19:07:16 <gundalow> oh, Felix already did it (CI)
19:07:34 <gundalow> nothing else from me
19:08:02 <felixfontein> #topic Blog post for Ansible 3.0.0, and potential delay of 3.0.0 release: https://github.com/ansible/community/issues/539#issuecomment-776930666
19:08:06 <felixfontein> dmsimard: your topic :)
19:08:26 <dmsimard> The gist of it is that when we announced 3.0.0b1, we got an influx of questions about 3.0.0 and we started putting together a comprehensive blog post/Q&A about it but it's not ready yet.
19:08:42 <dmsimard> We hope it will be ready by next tuesday but in case it isn't, we would like to consider slipping the release until at most thursday because it will be highly beneficial to users.
19:09:28 <felixfontein> sounds like a good idea to me
19:09:42 <jillr> agreed
19:10:11 <felixfontein> so this would be a blocker :)
19:10:15 <abadger1999> +1 from me
19:10:30 <felixfontein> (the announcement said 3.0.0 will be released on Feb 16 if there are no blockers)
19:10:39 <acozine> +1 and also let me know if you want help with the blog post
19:10:54 <abadger1999> Well... I think if we can't get it onto the official blog in time for a release on Thursday, we should publish it to an unofficial channel and release on Thrusday anyway.
19:10:54 <dmsimard> felixfontein: I suppose so
19:10:59 <felixfontein> btw, abadger1999, should we talk about 3.0.0 blockers today? do you want that as the next topic?
19:11:02 <abadger1999> So not a true blocker.
19:11:11 <samccann> should I slip in 'what if the docs aren't ready by feb 16' here for discussion?
19:11:21 <abadger1999> Sure.  I know of none so it's whether anyone else has one to nominate.
19:11:23 <felixfontein> samccann: sure
19:11:51 <felixfontein> abadger1999: the only one I can think of is the docsite, I guess
19:11:53 <gundalow> samccann: yup, sounds relevant :)
19:11:57 <samccann> ok gist of it is - yes, we have a rough PR that can split the docs, but we don't have a working solution (yet) to get both 2.10 docs and 3.x docs out of stable-2.10
19:11:58 <abadger1999> <nod>
19:12:15 <samccann> abadger1999 gave a quick implementation idea prior to this meeting that I'll need to look at
19:12:20 <abadger1999> #topic blockers for 3.0.0 -- docs split
19:12:37 <felixfontein> #undo
19:12:37 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fd4a449ced0>
19:12:38 <dmsimard> acozine: thanks, will share afterwards
19:12:39 <samccann> but my worry is - we need the PR cleaned up, reviewed/accepted into devel, then backported, and accepted into stable-2.10
19:12:51 <felixfontein> can we first finish the previous topic by officially saying yes/no?
19:12:59 <abadger1999> Roger that
19:13:02 <samccann> both of which require core team approval and this team approval.
19:13:17 <dmsimard> felixfontein: I haven't seen any objections but a formal vote is fair :)
19:13:24 <felixfontein> quick VOTE: is delaying 3.0.0 up until Thursday ok if the blog post isn't ready?
19:13:27 * samccann sits on hands cuz not sure if she's clobbered the existing topic
19:13:27 <felixfontein> +1
19:13:29 <dmsimard> +1
19:13:32 <tadeboro> +1
19:13:34 <dericcrago> +1
19:13:38 <samccann> +1
19:13:39 <jillr> +1
19:13:40 <cybette> +1
19:13:43 <acozine> +1
19:13:53 <gundalow> +1
19:14:10 <felixfontein> #agreed We delay Ansible 3.0.0 until at most Thursday if the blog post with all Q&A is not ready before Thursday. If it isn't ready by Thursday either, we do not block 3.0.0 because of the blog post anymore.
19:14:22 <felixfontein> #topic blockers for 3.0.0 -- docs split
19:14:26 <felixfontein> samccann: sorry, please continue :)
19:14:59 <samccann> heh ok,  so like I said, we have a lot of steps and problems to solve between now and next Tuesday (or Thursday).
19:15:30 <samccann> So we have a few options:
19:15:54 <samccann> 1 - have a 'hack' ready just in case we don't make it.  Something that forces a 3.x url into the existing 2.10 docs (with 3.x collections)
19:16:10 <samccann> 2. delay 3.0 if we don't have the real solution in place and the hack doesn't work
19:16:14 <samccann> 3. release w/o docs
19:16:50 <felixfontein> release without docs sounds ... strange. I think that will cause even more confusion than the jump to 3.0.0
19:16:56 <abadger1999> #info docs split has a PR and detailed implementation plan but it isn't completely coded yet, needs cleanup, and then needs approval from the core team and community members to get it merged.
19:17:01 <cybette> cybette-clock says: it's 2 minutes into the 3rd topic (docs split), and 15 minutes into the meeting
19:17:01 <acozine> is it still possible we could have the full pipeline at least in reviewable, non-WIP PR form by next Tuesday?
19:17:31 <dmsimard> abadger1999: can you share a link to the PR for posterity ?
19:17:41 <gundalow> release without docs sounds like a release blocker
19:17:55 <acozine> dmsimard: I think we have three PRs in various stages
19:17:59 <jillr> -1 releasing without docs
19:17:59 <samccann> I hope so, but I'm in over my head, so depend a lot on abadger1999 showing me the way forward so to speak. And he's got is own set of release work to do.
19:18:16 <abadger1999> #link https://hackmd.io/mvjYig49R5SQbNHzsd5jfQ?both#2-Jenkins-jobs
19:18:27 <tadeboro> Does 1 means newly included collections do not get their docs published?
19:18:35 <dmsimard> abadger1999: thanks
19:18:47 <abadger1999> Looking for the PR link too...
19:18:50 <samccann> 1 means new collections get their docs.. it's just forcing things through 'somehow'.
19:18:56 <felixfontein> tadeboro: the hack should include new collection docs
19:19:10 <samccann> so instead of getting the PR working, we just hack away in a special branch and special jenkins job to get it out there
19:19:28 <abadger1999> #link https://github.com/ansible/ansible/pull/73421
19:19:29 <github-linkbot> https://github.com/ansible/ansible/pull/73421 | open, created 2021-01-29T20:21:23Z by samccann: [WIP] Create separate core docs using 2 index files [WIP,affects_2.11,docs,needs_ci,needs_rebase,support:core,test]
19:19:50 <samccann> oh and I need to rebase said PR as well ;-)
19:20:02 <felixfontein> yep, just saw that too :)
19:20:19 <felixfontein> are the two older PRs dead (https://github.com/ansible/ansible/pull/73362, https://github.com/ansible/ansible/pull/73299)?
19:20:19 <github-linkbot> https://github.com/ansible/ansible/pull/73362, | open, created 2021-01-25T21:05:02Z by samccann: [WIP] Make coredocs [WIP,affects_2.11,docs,docsite,has_issue,needs_rebase,networking,stale_ci,support:core,test]
19:20:20 <github-linkbot> https://github.com/ansible/ansible/pull/73299)? | open, created 2021-01-19T21:35:25Z by samccann: [WIP] Create ability to make core docs separate from Ansible docs [WIP,affects_2.11,docs,needs_rebase,stale_ci,support:core,test]
19:20:30 <samccann> i've been 'waiting' to do that because it will be a little painful so didn't want to do it more  than once
19:21:04 <samccann> yes the older PRs are dead. I just left them there for now because abadger1999 taught me some tricks in there and I want  to be able to find those tricks in case I still need 'em.
19:21:12 <felixfontein> ok :)
19:21:16 <tadeboro> In that case, option 1 sounds the least bad for the Ansible users.
19:21:29 <tadeboro> And 3 is not really an option IMHO.
19:21:39 <felixfontein> I agree. a hack is better than nothing (i.e. 3), but 1. would be preferred
19:21:45 <felixfontein> the question is how long would 1. take
19:22:15 <felixfontein> and how can we (community) help with 1.?
19:22:37 <samccann> 1 is the hack. I'd guess we could figure that out in a day? And wouldn't require merging anything so probably only needs a few reviewers etc (as in we publish from a hack branch just to get the job done)
19:22:59 <felixfontein> ah sorry, I confused 1 and 2...
19:23:43 <samccann> 2. - abadger1999 gave me some food for thought that once I parse it, I'll likely need some help on anything that's not a Jenkins job (since those aren't visible to the community)
19:23:43 <felixfontein> how long would 2. take? (the 'clean' solution) I guess it would be in the order of weeks?
19:24:13 <samccann> The actual work is probably a few days (based on back and forth getting help). I'm more worried about delays in approval.
19:24:15 <acozine> here's what the current hack gives us: http://docs.testing.ansible.com/ansible/3/ (note, those are actually the 2.10 docs, but the URLs say 3)
19:24:40 <abadger1999> I don't know how much the existing PR will need to be cleaned up but I think the all new things are doable pretty quickly (less than a day)
19:24:41 <samccann> yeah and we'd have to update that hack to give 3.x collections
19:25:11 <abadger1999> I think the python code that needs to be changed is less than 20 lines, for instance.
19:25:29 <samccann> ^^^  that's something ya may not want me touching ;-)
19:25:38 <felixfontein> :)
19:25:45 <samccann> my actual python skills stop at 'hello world'.
19:25:46 <abadger1999> Yeah, I can do that... started working on it between other things this morning
19:25:52 <samccann> heh.  cool
19:26:08 <abadger1999> and I agree, approval is the unknown to me.
19:26:22 <felixfontein> I can also help with Python, though I'm not (yet) very familiar with the docs build process (and haven't paid much attention to the split over the last weeks)
19:26:25 <samccann> ok so rather than keep going in this meeting, sounds like the way forward - work with abadger1999 to get the PR quickly into 'reviewable' state. Then beg for reviews
19:26:42 <abadger1999> Maybe I can approve for community and we can talk relrod into approving for core?
19:26:58 <samccann> yes that would be helpful to at least know who can approve for core.
19:26:59 <felixfontein> since feature freeze is Friday, I hope core team will have more time on Monday/Tuesday next week for reviews
19:27:07 <felixfontein> (if not everyone is vanishing into PTO or so :) )
19:27:29 <samccann> yeah in the perfect world, I'd have had this ready a week ago for reviews... but such is life (and limited makfile skills etc)
19:27:38 <gundalow> samccann: such is life
19:28:08 <samccann> ok i'm cool with moving the topic on. Just didn't want to sit in silence w/ my worries
19:28:15 <dmsimard> So in summary, considering we have opened the door to slipping until thursday, we could try to land the right bits without resorting to hacks in time before next meeting and have a topic to decide if we need to slip further or implement a hack ?
19:28:22 <gundalow> samccann: Thanks for raising it
19:28:23 <felixfontein> ok. back to the meeting: I think the consensus seems to be that not having docs for 3.0.0 is a blocker. should we vote on that?
19:28:35 <felixfontein> dmsimard: sounds good to me!
19:28:35 <acozine> no docs, no release
19:28:57 <felixfontein> VOTE: no release without docs (either real solution, or hack)
19:28:59 * gundalow is happy to educate anyone that thinks otherwise
19:29:07 <acozine> +1
19:29:07 <samccann> +1
19:29:07 <felixfontein> i.e. (some form of) docs is a blocker
19:29:09 <felixfontein> +1
19:29:09 <dmsimard> +1
19:29:10 <jillr> +1 no docs, no release
19:29:10 <cybette> +1
19:29:11 <abadger1999> +1
19:29:12 <lmodemal> +1
19:29:13 <tadeboro> +1
19:29:14 <gundalow> +1
19:29:20 <briantist> +1
19:29:25 * samccann thinks no docs no release sounds like a protest march ;-)
19:29:40 <felixfontein> #agreed no release without docs (either real solution, or hack) - so docs are a blocker for 3.0.0
19:29:43 <jillr> hehe, it would totally work
19:29:45 <felixfontein> samccann: yep, a bit ;)
19:30:00 <dmsimard> Let's reconvene on the topic next week if there is still a blocker
19:30:06 <gundalow> plan
19:30:26 <felixfontein> should we vote on whether to try the real thing until next Wednesday, and resort to hack if it doesn't work (or is clear that it will be merged a few days later) only then?
19:30:49 <abadger1999> Probably better just for samccan and I to know that both are options
19:30:49 <gundalow> Do we know enough?
19:31:08 <felixfontein> we could also vote on that we should concentrate on a hack now if the majority wants that (though I don't think there's a majority for that)
19:31:15 <samccann> yeah. we can report in Tuesday's DaWGs meeting what the haps are (or earlier if it's all working and ready for review)
19:31:16 <cybette> cybette-clock says: 17 minutes in topic "blockers for 3.0.0 -- docs split", 30 minutes into meeting
19:31:27 <abadger1999> We;ll try to implement the real thing until we find something that is taking too long and we only have time to implement the real thing.
19:31:30 <samccann> LOL cybette-clock++
19:31:33 <dmsimard> felixfontein: hacks are no good tech debt and I would much rather we focus on the real thing
19:31:55 <felixfontein> dmsimard: I fully agree - but maybe someone thinks differently, at least in this situation
19:32:05 <dmsimard> it's a plan B :)
19:32:12 <cybette> samccann :) just wanna differentiate between things I say occasionally vs the time keeping
19:32:19 <samccann> yeah let's wait on the hack. if we  aren't ready for review by sometime on Tues, we can reconsider the hack
19:32:43 <felixfontein> VOTE: work on the real thing until at least next Tuesday (DaWGs meeting), and only resort to hack when it is clear by then that the real thing won't get completed anytime soon
19:32:47 <felixfontein> +1
19:32:49 <dmsimard> +1
19:32:50 <briantist> +1
19:32:51 <tadeboro> +1
19:33:03 <jillr> +1
19:33:14 <cybette> +1
19:33:17 <samccann> +1
19:33:42 <abadger1999> +1
19:34:03 <acozine> +1
19:34:05 <lmodemal> +1
19:34:14 <felixfontein> #agreed work on the real thing until at least next Tuesday (DaWGs meeting), and only resort to hack when it is clear by then that the real thing won't get completed anytime soon
19:34:18 <felixfontein> great :)
19:34:23 <felixfontein> anyone else has other potential blockers for 3.0.0?
19:35:05 <felixfontein> abadger1999: I think https://github.com/ansible-community/antsibull/pull/238 is a bit of a blocker, since we move a lot of stuff around in 3.0.0, but I would think / hope that it will be merged by then
19:35:06 <github-linkbot> https://github.com/ansible-community/antsibull/pull/238 | open, created 2021-01-17T13:02:08Z by felixfontein: antsibull-docs: process routing metadata [enhancement]
19:37:15 <abadger1999> Yeah, that would be extemely nice to get in.
19:37:35 <abadger1999> I think I can commit to getting it fully reviewed.
19:37:45 <felixfontein> cool, that would be great!
19:37:48 <abadger1999> Probably not both that and breadcrumbs, though.
19:38:09 <felixfontein> this one is more important than breadcrumbs
19:38:33 <abadger1999> Cool.  I agree.
19:38:46 <acozine> we can easily add breadcrumbs on some random day; if we're going to add stub pages, it's best to do it with a release
19:38:59 <felixfontein> samccann: acozine: if you have a bit of time, can you take a look at that PR for wordsmithing?
19:39:17 <acozine> felixfontein: yep, I can do that today
19:39:31 <felixfontein> thanks!
19:39:57 <felixfontein> ok, if there are no more potential blockers, let's continue with some PRs on the collection requirements
19:40:10 <felixfontein> #topic Python compatibility: https://github.com/ansible-collections/overview/pull/151
19:40:10 <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:40:46 <felixfontein> the PR contains the parts on Python versions we discussed and voted on last weeks
19:40:51 <felixfontein> s/weeks/week/
19:45:14 <felixfontein> any comments on this?
19:45:17 <cybette> cybette-clock says: 5 min in topic "Python compatibility", 45 minutes into meeting
19:45:39 <felixfontein> is everyone reading the PR, or doing something else? :)
19:45:42 <acozine> it could use a few copyedits, but I can do those post-merge; it's late for ompragash now
19:46:03 <cybette> ah yes it's past midnight for him
19:46:13 <samccann> does it need to merge today?
19:46:14 <acozine> I was reading it . . . started reading the comments, then gave up on finishing those and switched to the files view
19:46:31 <dmsimard> I was reading it -- I'm conflicted on this: while core is considering bumping controller requirements to py38 here we are talking about collections should be supporting 2.6
19:46:36 <gundalow> hum, might be missing it, though I don't see controller vs remote node
19:46:59 <felixfontein> dmsimard: also ansible-core 2.11 still supports 2.6
19:47:00 <felixfontein> AFAIK
19:47:10 <gundalow> ompragash is off tomorrow
19:48:00 <felixfontein> and ansible-core 2.11 still supports 2.7+ on controller AFAIK, it just prints a big warning - support will only be removed in ansible-core 2.12
19:48:10 <felixfontein> (at least that's what I know)
19:48:23 <abadger1999> felixfontein: +1
19:48:47 <abadger1999> Yeah, the more I've thought about the "big warning" argument, the more I've realized it's a deprecation warning.
19:49:02 <felixfontein> so for Ansible 3 and 4, this is still fine. and we can revise once Ansible with ansible-core 2.12 is coming up :)
19:49:03 <abadger1999> And you don't print a deprecation warning the same release as you remove support.
19:49:30 <felixfontein> (I don't even know how the warning looks like...)
19:50:53 <abadger1999> I had a list of (I think) three things that were kind of underpinings to how this policy should be written last time.
19:51:00 * abadger1999 goes looking in meeting log
19:52:02 <felixfontein> the warning is as follows:
19:52:03 <felixfontein> [DEPRECATION WARNING]: Ansible will require Python 3.8 or newer on the controller starting with Ansible 2.12. Current version: 2.7.18 (default, Apr 20 2020, 19:34:11) [GCC 8.3.0]. This feature will be removed from ansible-core in version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
19:52:13 <abadger1999> (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:52:56 <felixfontein> so it is a deprecation warning, i.e. ansible-core 2.11 still supports 2.7+ on controller side and collections should support that (if possible)
19:52:58 <abadger1999> So my answer to (1) is, there should be separate requirements for controllerside vs remoteside.
19:53:07 <felixfontein> abadger1999: I agree on 1
19:53:08 <dmsimard> abadger1999: the current proposal in the PR doesn't differentiate those
19:53:38 <abadger1999> dmsimard: yeah, so that's a change that needs to be made.
19:53:42 <gundalow> abadger1999: agreed
19:54:06 <jillr> I got bogged down reading the pr comments... I'm basically +1 everything Paul has said for controller-side collections once we get to 2.12
19:54:32 <jillr> and it would be good to differentiate the requirements now
19:54:45 <abadger1999> (2) I think my answer is, if it is at all possible for a plugin to run on the remote side , then it needs to obey the remote side python requirements.  It doesn't matter if it's used controllerside 95% of the time.... if there is a use case for 5% of the time, then we should do what we can to make it "Just Work" for users.
19:55:25 <abadger1999> It's kind of a global "ansible feature" and letting things get out of sync without reason destroys that feature.
19:55:26 <felixfontein> *every* module (that's not just an action plugin without a module) has a possibility of being run on a remote system
19:56:01 <tadeboro> felixfontein: Not if they are meant to be used with things like httpapi connection plugin.
19:56:05 <jillr> abadger1999: what would be an example of that? I've having trouble thinking of something in the cloud and network contexts
19:56:29 <abadger1999> Yeah.  So unless there's soemthing nonstandard that I'm not thinking of, I think the policy should make modules obey remoteside python requirements.
19:56:47 <abadger1999> jillr: Of what, the 5% case?
19:56:47 <felixfontein> jillr: your ansible controller might not be able to connect to the cloud (or the internet in general) :)
19:57:05 <abadger1999> Heh, felixfontein gave the example I was just about to give.
19:57:06 <jillr> felixfontein: then my modules would 100% fail  :)
19:57:20 <abadger1999> jillr: not true.
19:57:20 <jillr> regardless of python version
19:57:23 <felixfontein> jillr: why? you could run them on a jump host that can reach the cloud/internet
19:57:29 <abadger1999> jillr: Bastion host.
19:57:37 <jillr> AH ok I musunderstood
19:57:57 <felixfontein> it's probably a LOT more common for private clouds that are not reachable from the internet, than the other way around
19:58:19 <abadger1999> I'm sitting on a network in $PARANOID_CORP.  My laptop can't directly talk to amazon.  But there is a designated bastion host which can.  I use ansible to run the amazon modules on the bastion host to configure my amazon hosts.
19:58:35 <jillr> I thought you mean like, there is no way for the playbook to reach the internet, period
19:58:39 <felixfontein> and that @#$@$ bastion host runs RHEL4 :P
19:58:39 <abadger1999> <nod>
19:58:50 <abadger1999> hehe :-)
19:59:13 <felixfontein> I guess most cloud SDKs won't install on that ;)
19:59:24 <jillr> I'd have to defer to pabelanger in the networking case then, boto doesnt support py2.6 so I get a pass
19:59:31 <felixfontein> jillr: which Python versions are supported by boto3 / botocore?
19:59:45 <jillr> 2.7 and later, for the time being (py3 only "soon")
19:59:55 <felixfontein> yep, if the SDK you use doesn't support 2.6, your module doesn't need to support it either
20:00:03 <abadger1999> <nod>  Although you wouldn't get a pass on the python-2.7  or python-3.6 and python-3.7 requirement (at least not yet)
20:00:19 <felixfontein> (except if there are reasonable old versions which still do, and they still work with the cloud, and which you support ;) )
20:00:25 <jillr> yeah I'm just trying to think of the broader "controller only modules" context, beyond my specific use case
20:00:30 <cybette> cybette-clock says: 20 min in topic "Python compatibility", 1 hour into meeting
20:00:34 <abadger1999> Yeah.
20:00:48 <felixfontein> I'm not very familiar with other connection types like httpapi and the network ones
20:00:52 <pabelanger> for network, we don't support 2.6 today
20:00:55 <jillr> felixfontein: technically they're already dropped 2.7 support, but it still works so I consider it something we support
20:00:59 <abadger1999> PROPOSAL: Ask that something separating controllerside and remote side be added to the draft
20:01:04 <felixfontein> whether modules using these can actually run on remote machines
20:01:14 <felixfontein> +1
20:01:20 <abadger1999> +1
20:01:22 <jillr> which the boto dev team agreed with when I brought it up
20:01:28 <jillr> +1 proposal
20:01:34 <tadeboro> httpapi plugin has a localhost assumption baked-in.
20:01:57 <acozine> +1
20:01:58 <tadeboro> +1 for making clear what control node vs remote node requirements are
20:02:04 <samccann> +1
20:02:07 <gundalow> +1
20:02:11 <felixfontein> pabelanger: how is it with the network modules, is there any possibility to run them on a bastion host without executing ansible-playbook there?
20:03:02 * lmodemal hard stop at 3pm. Sorry I have to leave :(
20:03:14 <felixfontein> lmodemal: thanks for being here until now!
20:03:14 * acozine waves to lmodemal
20:03:42 <pabelanger> felixfontein: will diver to Qalthos for details, but I believe people setup ssh proxy in ssh_config for it
20:03:55 <pabelanger> but everything is still running controller side
20:04:17 <felixfontein> pabelanger: ok, so there's no way to not run it on controller side
20:04:24 <pabelanger> right
20:05:15 <pabelanger> that's mostly why we split network jobs to controller / appliance model.  A single node / all in one doesn't really fit
20:05:35 <abadger1999> <nod> As long as that holds true, I think it's okay to use controller-side requirements rather than remote-side.  If it is possible to run them on other hosts, just not common to do so, then I think it needs to use remote-side requirements.
20:05:48 <felixfontein> abadger1999: +1
20:05:53 <pabelanger> yah, I think that is fair
20:05:58 <briantist> +1
20:06:44 <felixfontein> hmm, is module_utils in such a collection also considered controller-side? since other collections could in theory include it and run it remotely
20:07:09 <abadger1999> I think module_utils would need to be considered remote side.
20:07:38 <abadger1999> Ehhh....... that's painful.
20:07:44 <felixfontein> so even if a collection only has controller-side modules, module_utils still needs to support 2.6+ (assuming it includes no libraries that require something newer)?
20:07:52 <felixfontein> yes, indeed :)
20:08:57 <tadeboro> Ugh, that one is bad. Ansible collections needs to have a way of telling other collections to bugger off and stop reusing stuff ;)
20:08:57 <abadger1999> I'm going to ignore module_utils for just a moment so we can make a proposal to try to record where we're at.
20:09:22 <felixfontein> tadeboro: only use files with _ prefix in module_utils ;)
20:09:27 <dmsimard> I would also like to comment: ugh
20:10:00 <felixfontein> (one thing why I don't like inter-collection dependencies between collections not developed in sync ;) )
20:10:15 <tadeboro> Clarifying remote/control node requirements seems like a good start. We can probably hammer out the details later.
20:10:27 <abadger1999> PROPOSAL: Ask that the draft define controller-side and remote-side.  If it's impossible for the plugin/module to rub remotely, then it can use the controller-side python requirements.  If it is possible, just uncommon in practice, that it can run remotely, then it has to follow the remote side python requirements.
20:10:38 <felixfontein> s/rub/run/
20:10:39 <tadeboro> And by details I mean "what is control-node-only code" and such things.
20:10:49 <cybette> cybette-clock says: 30 min in topic "Python compatibility", 1h 10m into meeting
20:11:11 <felixfontein> Appendum to proposal: ignore module_utils for now
20:11:41 <gundalow> Yup, I'm OK with ignoring module_utils to allow the rest to progress
20:11:48 <abadger1999> PROPOSAL: Ask that the draft define controller-side and remote-side like this: If it's impossible for the plugin/module to rub remotely, then it can use the controller-side python requirements.  If it is possible, just uncommon in practice, that it can run remotely, then it has to follow the remote side python requirements.  Note that how module_utils  falls into this needs to be hashed out
20:12:03 <dmsimard> +1
20:12:04 <felixfontein> +1
20:12:06 <tadeboro> +1
20:12:07 <acozine> +1
20:12:08 <abadger1999> +1
20:12:10 <felixfontein> with s/rub/run/ :)
20:12:21 <gundalow> +1
20:12:22 <dmsimard> no, no, rub is fine :D
20:12:24 <acozine> heh
20:12:37 <dericcrago> +1
20:12:37 <acozine> it's cold here, I could use a little code to rub my hands with
20:12:54 <abadger1999> #action abadger1999 will update PR, asking that both proposals are worked into the draft.
20:12:54 <felixfontein> do we need a community.massage collection?
20:13:01 <jillr> +1
20:13:24 <acozine> felixfontein: yes!
20:13:26 <samccann> rather late +1
20:13:40 <felixfontein> abadger1999: thanks!
20:13:50 <felixfontein> ok, another PR for the collection requirements:
20:13:51 <felixfontein> #topic Docs clarity: https://github.com/ansible-collections/overview/pull/152
20:13:52 <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
20:14:00 <tadeboro> felixfontein: Only if community.massage gets certified ;)
20:14:05 <felixfontein> I hope this requires less discussion ;)
20:14:08 <abadger1999> One moment, let me info something
20:14:11 <abadger1999> #undo
20:14:12 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fd4a3c3a790>
20:14:25 <felixfontein> tadeboro: I'd prefer inclusion in Ansible 4, the quality is better in general ;)
20:14:53 <abadger1999> #info Still need to talk about   (*) module_utils,  (*) minimum versions of python2 and python3 controller and remote side? (*) When should these versions be updated?
20:15:00 <abadger1999> #topic  (3) minimum versions of python2 and python3? (4) When should these versions be updated?
20:15:05 <abadger1999> #undo
20:15:05 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fd4a449c750>
20:15:17 <abadger1999> #topic Docs clarity: https://github.com/ansible-collections/overview/pull/152
20:15:28 <dmsimard> This one is about clarifying the requirements on the DOCUMENTATION, EXAMPLES and RETURN blocks and should be straightforward enough
20:15:30 <felixfontein> I hope this PR is more straightforward :)
20:16:18 <dmsimard> note, this is easier to review in the "rich diff" https://github.com/ansible-collections/overview/pull/152/files?short_path=dacab21#diff-dacab21f27a6aa218b8dcaafcf6f5685df0ab52f231afa16e7a9ab5284b72c68
20:17:06 <samccann> i'm stuck a bit on 'do we call it ansible-base or ansible-core'.  Technically, the developer could be on either at this point.
20:17:14 * samccann wants base to just go away as a name
20:17:38 <briantist> 😲I've never seen the "rich diff" button, that's awesome
20:17:41 <dmsimard> yeah the limbo between base and core will haunt us for a while longer
20:18:03 <felixfontein> samccann: I often write ansible-base/-core because of that ;)
20:18:31 <acozine> I've got a few wordsmith-y suggestions for this PR
20:18:36 <abadger1999> dmsimard: only until it's renamed to ansible-framework
20:18:40 * acozine is writing them as suggestions now
20:18:50 <felixfontein> oO
20:18:50 <dmsimard> abadger1999: bcoca had some other great suggestions too
20:18:50 <acozine> abadger1999: bite your tongue!
20:19:26 <felixfontein> let's rename the ansible-base/core package for every 'major' relesae, just to piss off people a bit more...
20:19:34 <briantist> `Ansible X` (the X makes it sound cool)
20:19:44 <felixfontein> briantist: the version after that: ansible-y
20:20:00 * abadger1999 is sorry for sidetracking us
20:20:01 <briantist> Ansible eXtreme (sponsored by Mountain Dew)
20:20:10 <briantist> ok sorry no more 😬
20:20:18 <samccann> heh
20:20:23 <dmsimard> acozine: happy to review wordsmith proposals in the PR
20:20:45 <felixfontein> do we want to wait a bit for the wordsmithing and then vote, or vote next week?
20:21:03 <felixfontein> (or maybe return to this topic later today?)
20:21:09 <cybette> cybette-clock says: 5 min in topic "Docs clarity", 1h 20m into meeting
20:21:15 <dmsimard> in the best interest of time, it can marinate until next week as it's not blocking anything I think
20:21:25 <felixfontein> ok, good
20:21:41 <felixfontein> #topic Collection checklist: check tests/integrations/ for blobs? https://github.com/ansible/community/issues/539#issuecomment-774705929 (andersson007_)
20:22:07 <felixfontein> andersson007_ suggested to look at tests/integrations/ for binary blobs during collection review
20:22:10 <dmsimard> need to drop to pick up kids from school, be back later
20:22:42 <felixfontein> which more generally raises the question of whether we want tests/ inside Ansible itself or not (I'd argue that tests/sanity/ should *always* be included)
20:22:47 <felixfontein> see you dmsimard!
20:23:18 <felixfontein> we had discussions earlier about moving tests to a separate archive on release
20:23:30 <felixfontein> so far concerns were that we have to deliver them somehow for licensing reasons I think
20:23:40 <felixfontein> is that still true, or has there been some development on that topic?
20:23:57 <felixfontein> abadger1999: I think you were mentioning GPL(v3) w.r.t.
20:23:57 <acozine> wordsmithing is done
20:24:18 <briantist> agreed with the point of coupling it with including tests or not, there's little reason to inlcude tests that rely on a blob if you're not going to include the blob
20:24:43 <abadger1999> felixfontein: legal has not responded about what we can and cannot do
20:25:43 <abadger1999> I think we could test for things that don't belong and ask that upstream remove them
20:25:51 <abadger1999> No legal ramifications there.
20:26:16 <abadger1999> Doing it ourselves runs into whether we're still shipping the preferred form of modification or not.
20:26:39 <tadeboro> But test fixtures are not something one could remove easily (if at all).
20:26:54 <abadger1999> tadeboro: yeah.
20:26:56 <felixfontein> at least not without also removing the tests :)
20:27:36 <misc> kinda surprised that the issue of "preferred form of modification" never intersected with "tabs vs space" debate
20:29:54 <felixfontein> abadger1999: is creating a separate test distribution ok, or is that also something legal has to look at first?
20:31:03 <cybette> cybette-clock says: 10 min in topic "Collection checklist", 1h 30m into meeting
20:32:03 <abadger1999> felixfontein: I think they'd have to look.  But we would need to design what we think  it should look like and then run that by them.
20:32:39 <felixfontein> hmm. ok. so if nobody volunteers to work on that now, I guess we can skip the topic until later :)
20:32:46 <abadger1999> Yeah.
20:34:08 <felixfontein> #info moving tests/ into its own distribution: legal would have to look at this first, and for that someone has to create a POC so they have something to look at
20:34:47 <felixfontein> #topic How often should Ansible major releases be made per year?
20:34:58 <felixfontein> this is a topic which came up several times already
20:35:28 <felixfontein> I guess it also depends on what release cycle ansible-core will eventually settle to, but maybe we can already think/discuss this a bit and maybe even have some upper/lower bounds on this number
20:35:43 <abadger1999> I think I have the main options here: https://hackmd.io/y7BBcweNR3aRVLuMbKkDxw#Proposed-Extremely-Tentative-Schedule-for-Ansible-500
20:36:09 <felixfontein> I personally would try to keep this number low, i.e. at most two major releases per year in general, since every major release contains breaking changes that requires users to potentially go through all their content
20:36:44 <felixfontein> nice, I haven't read that yet
20:38:26 <acozine> making a release involves a lot of overhead/effort
20:38:53 <acozine> on the other hand, the more frequently you do it, the more incentive you have to make the process quick and easy
20:39:00 <gundalow> Having a decision for 4.0 is good
20:39:36 <felixfontein> I guess 3 and 4 are special, in that they can have a very atypical release frequency
20:40:01 <acozine> if we did quarterly releases, we could set up a rhythm of "even numbered releases jump core versions; odd numbered releases don't" - so 4.0 based on 2.11; 5.0 still on 2.11; 6.0 on 2.12; etc.
20:40:09 <acozine> a bit like the ubuntu LTS cadence
20:40:32 <felixfontein> then we should have LTS versions though
20:40:36 <cybette> cybette-clock says: 6 min in topic "Ansible (major) release frequency", 1h 40m into meeting
20:40:42 <acozine> heh
20:40:42 <tadeboro> I like having thigs released often. But only if the releases do not break backward-compatibility. Potetntially breaking my playbooks every three months is not OK.
20:40:49 <felixfontein> so that people do not have to work with breaking changes all the time
20:41:12 <acozine> well, wouldn't the even-numbered releases be LTS-ish?
20:41:28 <acozine> they'd get updates to the underlying core version, right?
20:41:31 <abadger1999> tadeboro: <nod>  if everyone shares that, then allowing new features into the every-three-weeks releases probably took most of the pressure off.
20:42:08 <felixfontein> I agree with tadeboro, having new features which keep backwards compatibility is a great thing, and the thing that most users wanted I think
20:42:15 <felixfontein> nobody wants more breakages in shorter time :)
20:42:19 <felixfontein> (or almost ;) )
20:42:21 <acozine> ahhh, so we'd still do releases every three weeks - 3.1, 3.2, etc.
20:42:35 <acozine> but wait on 4.0 for the next core release?
20:42:44 <gundalow> I need to drop off now
20:42:47 <gundalow> Thanks all
20:42:48 <abadger1999> acozine: I think that felixfontein is thinking our "when a new major version comes out, the old version doesn't get anymore updates" is what keeps us from having an LTS.
20:42:50 <acozine> bye gundalow
20:42:55 <felixfontein> thanks and bye gundalow!
20:43:00 <abadger1999> bye gundalow !
20:43:07 <felixfontein> abadger1999: exactly
20:43:16 <acozine> ah, gotcha
20:43:22 <felixfontein> so if we have more major releases per year, we would have to release more major version streams in parallel
20:43:34 <felixfontein> which is also more work for the people doing the releases
20:43:35 <cybette> bye gundalow
20:44:08 <abadger1999> Yeah, that's compelling.  Maybe 6 month releases and we re-evaluate if someone volunteers to work on an LTS/having a supported older version.
20:44:28 <acozine> sounds good
20:44:43 <felixfontein> also having LTS and more major releases means that upgrading from one LTS to the next is more annoying, since you have to go through multiple porting guides
20:44:47 <tadeboro> I like the synced version because if I need to deal with the possibility that the core broke my stuff, I might as well go over the collections that I use.
20:44:52 <samccann> just so I understand - if I want a more recent collection, I'm still free to download it from galaxy (so long as it's compatible w/ the Ansible version I have installed), right?
20:45:00 <felixfontein> (and the number of docsites that need to be maintained increases)
20:45:00 <tadeboro> samccann: Yes.
20:45:12 <felixfontein> samccann: yes
20:45:21 <samccann> then my initial feeling is sync Ansible with ansible-core
20:45:38 <samccann> and evaluate after a year of that to see if the community is screaming for faster
20:45:51 <felixfontein> sounds like a good plan! (it is also what I'd prefer ;) )
20:46:04 <samccann> great minds think alike felixfontein!!
20:46:22 <felixfontein> :)
20:47:05 <felixfontein> is anyone (else/still) arguing for more frequent major releases than twice per year?
20:47:51 <abadger1999> not i
20:48:10 <sivel> I think I provided info about the core planned release cadence of April/October, but if not, there ya go ;)
20:48:42 <felixfontein> sivel: I heard it several times from different people, I don't remember whether you officially said that yet or not ;)
20:49:07 <acozine> nope
20:49:08 <felixfontein> sivel: how final is that planning btw?
20:49:40 <abadger1999> I have an April/October ansible-core assumption  in the doc :-)
20:49:51 <sivel> oh, yeah, I remember seeing that
20:50:21 <sivel> I'm still armwrestling with product to answer the questions I ask, and not some other answer to some other non-asked question
20:50:31 <sivel> but it's what we're currently operating off of
20:50:32 <cybette> cybette-clock says: 16 min in topic "Ansible (major) release frequency", 1h 50m into meeting
20:50:56 <felixfontein> sivel: sounds familiar :)
20:51:49 <samccann> lol!!!
20:51:53 <sivel> I have a meeting on Monday that I'll use to try to get this confirmed
20:52:14 <tadeboro> sivel: Good luck!
20:52:15 <bcoca> and a meeting on tuesday to confirm having the meeting on monday
20:52:19 <sivel> haha
20:52:27 <felixfontein> indeed, good luck!
20:52:49 <felixfontein> "the meeting yesterday didn't happen. sorry."
20:53:15 <samccann> don't forget the Thurs meeting that revokes Tuesday's confirmation of Monday's meeting
20:53:27 <samccann> ;-)  we're all here for ya sivel!
20:53:52 <bcoca> and i'll pay you for the hamburger on wed
20:54:29 <abadger1999> PROPOSAL: Unless something changes with ansible-core release schedules, ansible will plan on six month schedules for major releases targeting about a month behind ansible-core.
20:54:46 <acozine> +1
20:54:47 <tadeboro> +1
20:54:54 <cybette> +1
20:54:55 <samccann> +1
20:55:05 <dericcrago> +1
20:55:17 <jillr> +1
20:55:26 <abadger1999> +1
20:55:45 <felixfontein> +1
20:56:27 <dmsimard> +1 (I'm back)
20:56:27 <felixfontein> cool :)
20:56:32 <dericcrago> that should give us ~7-8 minor releases based on a 3 week cadence
20:57:01 <felixfontein> #agreed Unless something changes with ansible-core release schedules, ansible will plan on six month schedules for major releases targeting about a month behind ansible-core.
20:57:08 <felixfontein> #topic open floor
20:57:14 <felixfontein> ok, we're almost at two hours
20:57:30 <felixfontein> if nobody has something important to talk about, let's close the meeting in three minutes :)
20:57:42 <felixfontein> s/important/important and urgent/ :)
20:57:56 <acozine> heh
20:58:10 <jillr> shut it down  :)
20:58:21 <samccann> pull the plug!
20:58:24 <dmsimard> thanks everyone
20:58:29 <dmsimard> another long but productive meeting
20:58:39 <cybette> thanks all
20:58:46 <tadeboro> Bye all!
20:58:52 <jillr> thanks everyone!
20:58:56 <felixfontein> indeed!
20:59:02 <felixfontein> thanks everyone! :)
20:59:10 <felixfontein> #endmeeting