19:00:35 <felixfontein> #startmeeting Ansible Community Meeting
19:00:35 <zodbot> Meeting started Wed Mar  3 19:00:35 2021 UTC.
19:00:35 <zodbot> This meeting is logged and archived in a public location.
19:00:35 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:35 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:00:35 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
19:00:35 <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:40 <cybette> o/
19:00:42 <felixfontein> #chair dmsimard jillr cybette
19:00:42 <zodbot> Current chairs: cybette dmsimard felixfontein jillr
19:00:54 <felixfontein> the 'real' cybette-clock is back :)
19:01:03 <briantist> hello
19:01:05 <cybette> hehe :D thanks dmsimard for the great job last week!
19:01:17 <cyberpear> o/
19:01:28 * gundalow waves
19:01:30 <acozine> o/
19:01:32 <abadger1999> Howdy
19:01:37 <dmsimard> cybette-clock also made it's way to the docs meeting :p
19:01:49 <felixfontein> #chair briantist cyberpear gundalow acozine abadger1999
19:01:49 <zodbot> Current chairs: abadger1999 acozine briantist cyberpear cybette dmsimard felixfontein gundalow jillr
19:02:02 <andersson007_> o/
19:02:08 <felixfontein> #topic Updates
19:02:10 <felixfontein> #chair andersson007_
19:02:10 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dmsimard felixfontein gundalow jillr
19:02:16 <tadeboro> o/
19:02:19 * lmodemal I'll be lurking
19:02:20 <felixfontein> I don't have updates, so if anyone else has... :)
19:02:23 <felixfontein> #chair tadeboro lmodemal
19:02:23 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dmsimard felixfontein gundalow jillr lmodemal tadeboro
19:02:25 <lmodemal> Hi everyone o/
19:02:28 <cybette> maybe we need a clock-bot :)
19:02:45 <andersson007_> sounds good
19:02:46 * dericcrago waves
19:02:51 * samccann waves
19:02:53 <felixfontein> #chair dericcrago samccann
19:02:53 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro
19:02:54 <cybette> #info Ansible Contributor Summit is next Tuesday https://www.eventbrite.com/e/ansible-contributor-summit-202103-registration-141735886853?aff=irc
19:03:07 <dmsimard> no update from me
19:03:21 * tadeboro is in a read-only mode for another 20 minutes because kids
19:03:21 <samccann> cyb-clock rocks!
19:03:24 <felixfontein> I guess the Ansible 3.1.0 release will be next week?
19:03:34 <felixfontein> and there's the contributor summit next week!
19:03:42 <gundalow> exciting week
19:03:50 <samccann> #info Ansible core has its own docsite now  - https://docs.ansible.com/ansible-core/devel/index.html
19:03:52 <dmsimard> busy week :)
19:04:12 <felixfontein> \o/
19:04:26 <felixfontein> and the docsplit backport PR has been merged to stable-2.10
19:04:38 <felixfontein> docsplit = docsite split
19:05:04 <cybette> samccann: \o/
19:05:18 <samccann> yep. We most likely will be publishing ansible-base 2.10 to that ansible-core url as well, since 2.10 base is still getting updates, but Ansible the package is EOL
19:05:54 <felixfontein> I hope you mean Ansible 2.10, and not Ansible in general ;)
19:06:18 <abadger1999> Heh :-)
19:06:20 <samccann> hahaha! yes!  sorry Ansible 2.10 doesn't get updates since Ansible 3 came out, afaik. Unless y'all know otherwise
19:06:38 <abadger1999> No one has asked for it so far.
19:06:39 <felixfontein> samccann: I guess it can still happen, but it is not planned
19:07:04 <felixfontein> sooner or later some security issue will pop up, maybe we'll see a 2.10 release then
19:07:34 <abadger1999> #info Ansible-3.1.0 release scheuled for Tuesday, March 9, next week
19:07:36 <acozine> I thought we were only maintaining one version of the community package at a time?
19:08:11 <dmsimard> There is a topic next week about that
19:08:18 <dmsimard> at summit, I mean
19:08:19 <acozine> that when Ansible 3.0.0 released, Ansible 2.10 (the community package) went EOL
19:08:28 <acozine> ah, okay, so it's still under discussion
19:08:40 <felixfontein> so far it was "if nobody from the community wants to handle the release, there will be no more releases"
19:08:50 <abadger1999> I'm not planning on making another  release of ansible-2.10.x, even for security issues.  A security issue might prompt someone to step up, though.
19:09:07 <acozine> thanks for the clarification
19:09:37 <felixfontein> #topic community.general major release cycle adjustment
19:09:43 <felixfontein> a first topic :)
19:09:43 <felixfontein> #link https://github.com/ansible/community/issues/539#issuecomment-786879617
19:10:18 <felixfontein> now that the Ansible 3 and 4 schedules are more and more fixed, we should think about the community.general (and community.network) major release schedules
19:10:56 <felixfontein> I don't think it makes sense to make a major c.g/c.n release 1-2 months after a Ansible major release, and thus 4-5 months before the next major Ansible release that will pick up the new c.g/c.n major version
19:11:22 <abadger1999> <nod>
19:11:48 <abadger1999> Your option (ii) and (iii) both make sense to me
19:11:59 <felixfontein> I wrote down a couple of options in the link: i) keep schedule as-is, ii) shorten current cycle to align, then keep ~6-month schedule, iii) lengthen current cycle to align, iv) something else (someone would have to suggest)
19:12:24 <felixfontein> if someone has another idea, please bring it up :)
19:12:56 <briantist> Agreed with abadger1999 , personally prefer `ii` , would understand if `iii` is preferred by some, for additional caution
19:13:11 <felixfontein> I currently tend more to ii), which means that community.general 3.0.0 will be earlier than planned so that it will get included in Ansible 4.0.0
19:13:17 <tadeboro> Depends on how users get their content. For people installing from galaxy, schedule does not matter much.
19:13:30 <samccann> yeah that ^^
19:14:04 <samccann> in the back of my mind was the whole idea of collections revving independent of Ansible.  But I don't know how many people are downloading via Galaxy etc vs just getting it from Ansible the package
19:14:07 <briantist> right, that's part of why I prefer earlier, we should encourage that type of usage, and being defensive for the benefit of package users is also a bit worse for direct galaxy installers
19:14:08 <felixfontein> I like having 3.0.0 sooner than later because it is the version which removes a lot of deprecated baggage we took over from ansible/ansible, like the ovirt _facts modules that c.g inherited (instead of the ovirt collection)
19:15:02 <andersson007_> ii LGTM
19:15:17 <cybette> cybette-clock says: we're 6 min in topic "community.general release cycle", and 15 min into meeting!
19:15:25 <felixfontein> besides removal of _facts modules/aliases, it will contain a small set of breaking changes resulting from deprecations (I started working on a PR to remove them, if someone is interested: https://github.com/ansible-collections/community.general/pull/1926)
19:15:25 <github-linkbot> https://github.com/ansible-collections/community.general/pull/1926) | open, created 2021-02-27T11:04:11Z by felixfontein: Remove deprecated features scheduled for removal in 3.0.0 [affects_2.10,breaking_change,bug,cloud,community_review,files,module,module_utils,monitoring,notification,os,packaging,plugins,remote_management,system,tests,web_infrastructure]
19:15:41 <cybette> I'm leaning to (ii) as well
19:15:55 <briantist> sounds like we're already leaning toward consensus on `ii`, vote?
19:15:59 <jillr> IMO ii >> iii >> i
19:16:00 <andersson007_> felixfontein: it's in my review list
19:16:06 <felixfontein> andersson007_: thanks!
19:16:20 <felixfontein> does anyone prefers something else than ii?
19:16:33 <andersson007_> felixfontein: np:)
19:16:38 <samccann> my leaning would be (ii) as well if we are syncing to Ansible releases. As for whether we should sync, I guess we are syncing major releases here, so not like c.g isn't revving multiple times before then
19:16:38 <felixfontein> (i.e. does anyone wants a longer discussion, or should we vote now?)
19:16:53 <abadger1999> vote++
19:17:04 <andersson007_> let's vote
19:17:42 <samccann> let's vote on whether we vote!  (kidding)
19:17:57 * samccann ducks the rotten tomatoes being tossed at her
19:18:14 <felixfontein> VOTE: should we adjust the c.g and c.n major release cycles so they always release shortly before an Ansible major release? (since we decided more or less on a ~6 month delay between Ansible major releases, this means the current cycle will be shortened and then it continues in 6 month cycles)
19:18:22 <briantist> 😂🍅
19:18:54 <abadger1999> +1
19:18:55 <jillr> +1
19:18:56 <dericcrago> +1
19:18:57 <briantist> +1
19:18:57 <tadeboro> +0 (do not care because ansible-core + handpicked collections from galaxy is what I see as the future)
19:19:01 <cybette> +1
19:19:02 <felixfontein> if you want to toss a rotten tomato, turn your camera on first so we can have a recording of you soiling yourself and your computer ;)
19:19:03 <andersson007_> +1
19:19:10 <felixfontein> +1
19:19:15 <acozine> +1
19:19:46 <samccann> +1
19:19:55 <gundalow> +1
19:20:03 <felixfontein> looks like agreement :)
19:20:22 <felixfontein> #agreed we adjust the c.g and c.n major release cycles so they always release shortly before an Ansible major release
19:20:27 <acozine> we can always add extra c.g releases between package releases if tadeboro's vision comes true and folks are using build-your-own installations
19:20:51 <acozine> but having a full c.g release right before the package release makes a lot of sense
19:20:56 <felixfontein> #action felixfontein add the new c.g/c.n major release schedule to the c.g/c.n announcements and release documentation (somewhere in the community wiki)
19:21:26 <felixfontein> acozine: true. also c.g/c.n are a bit special since they have regular major releases, while most collections do not
19:21:53 <felixfontein> should we continue with the Python version discussion?
19:22:22 <felixfontein> abadger1999: have you read up what ompragash wrote in https://github.com/ansible-collections/overview/pull/151 ?
19:22:22 <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:25:15 <abadger1999> I like what he has in the comment.
19:25:25 <acozine> +1 for control node / managed node
19:25:36 <felixfontein> #topic Python version requirements: https://github.com/ansible-collections/overview/pull/151
19:25:41 <felixfontein> ok so let's discuss this :)
19:25:58 <abadger1999> Changing the terminology makes sense to me
19:26:29 <felixfontein> I'm not 100% sure about control/managed node, since `delegate_to: localhost` can use a different Python version than the controller, can't it?
19:27:00 <felixfontein> (not sure why someone would want to do that, but I'm sure that someone does it if it's possible :) )
19:27:05 <abadger1999> Yeah.......
19:27:36 <abadger1999> remote-side seems better than managed node.
19:27:48 <abadger1999> It's not exactly the same concept.
19:28:44 <abadger1999> and if we're going to use a different term for that, then we probably should use a different term for the controller-side as well.
19:29:37 <samccann> the problem there is our docs talk control node and managed node. But the collection requirements docs would talk about
19:29:46 <samccann> something and remote side node
19:29:57 <felixfontein> samccann: that's because it's two different concepts
19:30:10 <felixfontein> they are almost the same, but not 100% :)
19:30:28 <cybette> cybette-clock says: we're 5 min in topic "Python version requirements", and 30 min into meeting
19:30:35 <samccann> felixfontein: will the people who need to know, understand those differences? or do we also have to document  them. like 'remode side is a managed node and/or blablabla'?
19:30:54 <samccann> If developers already know all this, and if users don't ever need to care what a remote side is? then cool
19:30:58 <felixfontein> samccann: good question. it's probably better to document them, resp. have a longer explanation for them
19:31:21 <felixfontein> I think users don't need to know, but developers don't necessary know about it
19:31:39 <briantist> if you `delegate_to: localhost`, then that machine takes on both the roles of managed node and control node, if that helps
19:31:39 <abadger1999> controller-side: the plugins/modules only run under the same python interpreter/environment as the ansible script itself.    remote-side: it is possible for the plugins/modules to run under a different python interpreter/environment, even if it is uncommon in practice.
19:31:40 <samccann> yeah then I think a few more words to explain it to developers in that doc would be good
19:31:40 <gundalow> "When the manage node is not the same as the control node"
19:31:41 <jillr> if we've had this much discussin around it, we should definitely document it for developers
19:31:48 <gundalow> jillr: yup
19:32:19 <felixfontein> gundalow: even if they are the same, code might use another Python interpreter :)
19:32:20 <abadger1999> I think that's why we have definitions in the doc.
19:32:33 <gundalow> felixfontein: oooh
19:32:54 <felixfontein> abadger1999: we should probably expand them a bit
19:32:59 <abadger1999> But (a) maybe we can improve the definitions. or (b) maybe we need to not overload our terms? (controller and remote)
19:33:19 <abadger1999> felixfontein: Yeah
19:33:28 <felixfontein> "controller-side: It is impossible for the plugins/modules to run remotely": maybe add "; they always run in the same environment (Python interpreter, venv, ...) as ansible-core itself"
19:34:28 <felixfontein> abadger1999: good question. overloading could be OK because the terms are pretty similar, and for most people the differences can be ignored. on the other hand, having so close names for two things that are different is always problematic.
19:34:34 <abadger1999> Do we need to say "remotely" if we talk about the environment?
19:34:45 <felixfontein> not necessarily
19:35:05 <felixfontein> we could also use 'same environment as ansible-core' and 'potentially different environment than ansible-core'
19:35:18 <abadger1999> "controller-side: The plugins/modules always run in the same environment (Python interpreter, venv, host, etc) as ansible-core itself"
19:35:19 <felixfontein> though that's more to type :)
19:35:49 <briantist> kind of what I was getting at with the term `role`, the managed node need not be "remote" necessarily
19:36:47 <felixfontein> maybe 'controller-side' and 'generic-side'?
19:37:16 <felixfontein> (maybe the native speakers here have better ideas/words for that :) )
19:37:29 <briantist> `target`?
19:37:46 <felixfontein> 'controller-side' and 'target-side'?
19:37:47 <andersson007_> generic sounds confusing imo
19:38:13 <abadger1999> target-side does sound better.
19:38:34 <felixfontein> andersson007_: I know :)
19:38:58 <jillr> I'm a bit stuck on the term 'side' generally, but I don't know that I have a better suggestions
19:39:12 <abadger1999> environment?
19:39:25 <acozine> so the difference between "on the managed node/nodes" and "target-side" is that "target-side" can mean both "on a managed node" AND/OR "on a machine you've delegated to" . . . is that right?
19:39:25 <felixfontein> 'controller environment' and 'target environment'?
19:39:43 <jillr> environment or execution is where I'm leaning, but I'm admittedly rabbitholing a bit trying to think of every possible implication
19:39:53 <abadger1999> "controller-environment",    ["target-environment", "managed-environment", "other-environment"]
19:39:56 <felixfontein> 'execution environment'? ;)
19:39:59 <jillr> lol
19:40:07 <jillr> mayeb that's why I'm stuck on it
19:40:08 <acozine> we could just say "on the controller" for the one and "on any other device or machine" for the ohter
19:40:08 <gundalow> bad felix
19:40:14 <felixfontein> :)
19:40:15 <briantist> hahah but I do agree with feeling slightly negative on `side`
19:40:31 <briantist> even though I use it when explaining it to people too...
19:40:36 <cybette> cybette-clock says: we're 15 min in topic "Python version requirements", and 40 min into meeting
19:40:49 <felixfontein> abadger1999: I somehow dislike managed-environment (though I can't say why), but both target-env and other-env sound good to me
19:41:26 <abadger1999> acozine: That's not entirely correct, though.  If we wrap it into a sound bite size, I think that it's okay to be a little inaccurate (with a longer definition) but if we spell it out, then I feel like it should be 100% accurate
19:41:30 <abadger1999> felixfontein: <nod>
19:42:01 <abadger1999> I like "other-environment" the best... does that suffer from the "generic-side" problem or is it okay?
19:42:05 <jillr> cause we're trying to tell developers to think about the python environment the code will execute in, in theory can assume that developers will have some familiarity with that idea?
19:42:36 <felixfontein> jillr: I think so
19:43:05 <felixfontein> abadger1999: to me it sounds good
19:43:09 <jillr> so maybe we should approach it like python developer docs, rather than trying to tie it to how we present exactly user data in user docs
19:43:24 <acozine> I'm still not clear on how "remote-side" or whatever term we use is different from "on the managed node/nodes"
19:43:41 <acozine> what other use cases are involved?
19:44:08 <felixfontein> acozine: remote-side things can also run on the controller node (but on that in a different Python environment than controller-side)
19:44:57 <acozine> felixfontein: thanks
19:45:00 <abadger1999> "controller-environment: The plugins/modules always run in the same environment (Python interpreter, venv, host, etc) as ansible-core itself"  "other-environment: It is possible, even if uncommon in practice, for the plugins/modules to run in a different environment than ansible-core itself."
19:45:09 <felixfontein> so remote-side can be very not-remote, that's why having 'remote' in it is confusing :)
19:45:32 <felixfontein> abadger1999: +1
19:45:33 <jillr> abadger1999: yeah like that
19:45:41 <abadger1999> Cool
19:46:24 <abadger1999> Vote on that or should I just post it as a reply to ompragash 's PR and then we can vote on the PR once he's updated?
19:46:25 <cybette> even to me (not an ansible/python dev but have been in development), the term "environment" makes it clearer than "side"
19:46:40 <abadger1999> cybette: +1
19:46:41 <felixfontein> both is fine for me
19:46:57 <abadger1999> Cool, I'll just post that, then
19:46:59 <felixfontein> or does someone has other/more suggestions, and/or is unhappy with controller-env/other-env?
19:47:10 <felixfontein> (if you have so, write that quickly :) )
19:47:36 <felixfontein> (or if you need more time to think)
19:47:39 <samccann> good w what abadger1999 is suggesting
19:48:10 * samccann mutters to self about execution environments and hoping we haven't now overloaded the environment term
19:48:25 <felixfontein> :)
19:48:44 <jillr> at least we can say pyenv vs EE  :)
19:48:50 <felixfontein> one could say that 'execution environment' already overloaded 'Python environment', so.. :)
19:49:12 * acozine has flashbacks to discussions about the word "collection" from her library days
19:49:30 <samccann> AAHAHAH oh my
19:49:32 <felixfontein> :D
19:49:41 <felixfontein> I'm sure that didn't involve 'Ansible collections' ;)
19:49:41 <briantist> 😬
19:50:20 <acozine> it didn't, but I get a little tic under my eye if I edit too much stuff about collections in one day
19:50:27 <cybette> cybette-clock says: 25 min in topic "overloaded environments", and 50 min into meeting
19:50:43 <felixfontein> ok, abadger1999 feel free to add that to the PR!
19:50:49 <felixfontein> then hopefully we can finally vote on the PR next week!
19:50:57 <abadger1999> Cool.  Commented with that :-)
19:51:14 <felixfontein> #agreed controller-environment and other-environment are the terms we plan to use
19:51:44 <felixfontein> so, what's next?
19:52:57 <cybette> gundalow: can you confirm if we're having a hackathon next wednesday after contrib summit, and if so, we'll have that in lieu of the IRC meeting?
19:53:06 <felixfontein> we can discuss: 1) new content for c.g/c.n (continuing a discussion from last November), 2) requiring deprecations ahead of breaking changes (would need a lot of discussion), 3) maybe integrating https://github.com/Andersson007/ansible_reviewer with a ansible-test, ... something else?
19:53:41 <gundalow> cybette: yup, we will have a hackathon/PR day
19:53:48 <felixfontein> will we move/cancel next weeks meeting, or make a break during the hackathon (and try to keep the meeting short)?
19:54:10 <cybette> gundalow: great, thanks
19:54:11 <felixfontein> it would be nice to finally settle the python version PR, I hope that will be quick next time
19:54:16 <gundalow> If we have IRC meeting things we can make time for that
19:54:18 <jillr> "and try to keep the meeting short" squad goals  :)
19:54:29 <gundalow> jillr: like goals :P
19:54:34 <felixfontein> jillr: hehe yes ;)
19:55:56 <felixfontein> we can also start today with a short meeting, and continue with open floor, or a meta-discussion on what we want to discuss in the next meeting(s)
19:56:43 <abadger1999> Heh :-)
19:57:44 <felixfontein> on another note, all new collection applications should be reviewed until in 1.5 months (https://github.com/ansible-collections/ansible-inclusion/discussions/categories/new-collection-reviews)
19:58:04 <cybette> I propose we keep it short today, as we'll have 2 long days next week, and we can have IRC meeting sometime during hack day when we have quorum
19:58:08 <felixfontein> so far there are only three applicants, so it should be no problem, but maybe more will show up when the deadline comes closer
19:58:16 <felixfontein> #topic open floor
19:58:19 <felixfontein> cybette: +1
19:58:47 <cybette> #info Please check conference link + agenda, and propose topics for Contributor Summit https://hackmd.io/uZDSLOOdS1Kx0xfZVIATmQ
19:58:56 <abadger1999> gundalow brought up the idea to split the inclusion criteria and start versioning them.  I'm going to talk to the ansible ecosystem technical architects tomorrow and figure out what they want from it.  I think we'll have a better idea of what we can do for them once we know what their use cases are
19:59:20 <felixfontein> abadger1999: sounds good!
19:59:58 <gundalow> (This is the think I mentioned in IRC yesterday)
20:01:03 <felixfontein> it's probably a good idea to get more input on this, and then discuss it in 1-2 weeks when we have that information
20:01:20 <felixfontein> so if anyone has more input, please talk to gundalow and/or abadger1999!
20:01:34 <felixfontein> is there anything else, or should we close for today?
20:01:55 <tadeboro> Close? After only one hour? ;)
20:02:05 <felixfontein> tadeboro: exactly ;)
20:02:46 <andersson007_> tadeboro: thought it was a start of the meeting
20:03:09 <abadger1999> lol :-)
20:03:24 <felixfontein> #endmeeting