18:00:35 <felixfontein> #startmeeting Ansible Community Meeting
18:00:35 <zodbot> Meeting started Wed Oct 13 18:00:35 2021 UTC.
18:00:35 <zodbot> This meeting is logged and archived in a public location.
18:00:35 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:35 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:36 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:36 <felixfontein> acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping!
18:00:40 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:43 <dmsimard> o/
18:00:44 <jillr> o/
18:00:46 <cyberpear> o/
18:00:52 <andersson007_[m]> o/
18:00:53 <jtanner> hi
18:00:53 <tadeboro> o/
18:00:58 <cidrblock[m]> hey all
18:00:59 <felixfontein> #chair dmsimard jillr cyberpear tadeboro andersson007_[m] jtanner
18:00:59 <zodbot> Current chairs: andersson007_[m] cyberpear dmsimard felixfontein jillr jtanner tadeboro
18:01:12 <felixfontein> #chair cidrblock[m]
18:01:12 <zodbot> Current chairs: andersson007_[m] cidrblock[m] cyberpear dmsimard felixfontein jillr jtanner tadeboro
18:01:14 <gundalow> o/
18:01:14 <acozine> 0/
18:01:30 <felixfontein> #chair gundalow acozine
18:01:30 <zodbot> Current chairs: acozine andersson007_[m] cidrblock[m] cyberpear dmsimard felixfontein gundalow jillr jtanner tadeboro
18:01:40 <felixfontein> #topic Updates
18:01:54 <dmsimard> #info ansible-core 2.11.6 has been released
18:02:07 <acozine> \o/
18:02:11 <dmsimard> #info ansible 4.7.0 will be released today (soon)
18:03:06 <felixfontein> \o/
18:04:43 <felixfontein> and hopefully Galaxy will allow to publish collections again :) (or at least the one I'm trying to publish since this morning ;) )
18:04:53 <dericcrago> #info there is a testing-ansible-5 PPA https://launchpad.net/~ansible/+archive/ubuntu/testing-ansible-5
18:05:25 <dmsimard> felixfontein: the technical issues were not immediately clear to me but some services may have been stuck and restarted, it should be good now.
18:05:44 <felixfontein> dmsimard: ah, good to know. I'll delete and re-create the tag then
18:06:02 <dmsimard> felixfontein: either that or I can re-trigger the zuul job
18:06:18 <felixfontein> dmsimard: just re-pushed it :)
18:06:27 <dmsimard> wfm
18:06:44 <felixfontein> #topic Clarify Python version restriction documentation
18:06:44 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/47
18:07:05 <felixfontein> since we couldn't find a solution last week we postponed this topic to this week
18:07:26 <felixfontein> we now have a suggestion by dmsimard, and I've added another suggestion which I think captures both what the PR actually wants to do and what dmsimard wants as well :)
18:07:41 <dmsimard> I'm OK with making it a MUST, apologies for the unintended phrasing
18:09:33 <dmsimard> felixfontein: the proposed phrasing you suggested makes it a requirement only if it diverges from what ansible-core supports -- would it be simpler if it is always a MUST ?
18:10:14 <felixfontein> dmsimard: I don't like the idea of having to repeat in the README and every plugin/module's documentation what ansible-core supports :)
18:10:41 <felixfontein> for collections like community.general this will be a huge PITA
18:11:17 <dmsimard> ah, from the perspective of a collection which has different requirements depending on the plugins and modules
18:11:25 <gundalow> I thought there was going to be something in `meta/runtime.yml` to define Python ranges for host and managed node
18:11:46 <dmsimard> I was running with the naive assumption that it would be a singular requirement that would be across the entire collection but I can see what you mean
18:11:52 <felixfontein> gundalow: there isn't, unfortunately; you can only state which ansible/ansible-base/ansible-core versions you support in there
18:11:56 <tadeboro> gundalow: Not sure if this is feasible for collections such as c.g where requirements are not unified.
18:12:13 <gundalow> If it's easier, maybe we should have one requirement for collections apart from community.general and community.network
18:12:33 <felixfontein> also for other collections it could be that some content has more specific requirements
18:12:46 <acozine> I like the "If your collection supports the same python versions as the current version of ansible-core, you don't need to document it" approach.
18:12:49 <felixfontein> like community.aws could have one set of requirements for modules using boto2, and another set of requirements for modules using boto3
18:12:54 <tadeboro> I think what felixfontein proposed is good enough for now (but I was already happy with the first proposal a week ago, sooo ... ;)
18:13:02 <andersson007_[m]> acozine: +1
18:13:20 <andersson007_[m]> i like the current version of the proposal
18:13:35 <felixfontein> acozine: I would even formulate it as "...as all versions of ansible-core the collection supports, ..."
18:13:50 <felixfontein> andersson007_[m]: with or without the last suggestion?
18:14:33 <andersson007_[m]> felixfontein: without:)
18:14:34 <dmsimard> felixfontein: your last suggestion has a SHOULD for modules/plugins, though
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:09 <felixfontein> dmsimard: that's basically for large collections like amazon.aws and community.aws, where it would be tedious to repeat these requirements in every module/plugin
18:15:41 <felixfontein> if basically all modules/plugins have the same requirements, I'm happy if they are only mentioned in the README
18:15:47 <jillr> felixfontein: doc fragments solves that, but I suppose there might be collections that wouldn't want to do that
18:15:58 <jillr> unless you mean in the raw code, vs the rendered docs?
18:16:32 <felixfontein> jillr: yes, I would solve that with fragments, but I guess that won't work in every case
18:16:33 <acozine> I'd maybe word this as `If your collection supports the same python versions as the current version of ansible-core, you do not need to document them. If your collection does not support those python version, you MUST document which versions it supports, in the README for the collection as a whole. If the modules and plugins in your collection support different python versions, you MUST document the supported versions for each individual module
18:16:33 <acozine> and plugin.`
18:16:36 <felixfontein> (I mean the rendered docs)
18:17:23 <felixfontein> acozine: that means that in c.g, every module and plugin has to mention all Python versions, since there are a handful that have more specific requirements
18:17:38 <briantist> o
18:17:41 <briantist> o/
18:17:44 <felixfontein> #chair briantist
18:17:44 <zodbot> Current chairs: acozine andersson007_[m] briantist cidrblock[m] cyberpear dmsimard felixfontein gundalow jillr jtanner tadeboro
18:17:44 <dmsimard> felixfontein: I wanna say that it's kind of important to have it in individual modules (however tedious that might be), even more so when they differ from module to module
18:18:18 <acozine> ah, I see
18:18:22 <felixfontein> dmsimard: I think for modules/plugins that support all Python versions that all supported ansible versions support, I don't think the supported versions need to be documented
18:18:32 <acozine> we have edge cases within the bigger collections
18:18:47 <dmsimard> felixfontein: that's fair, and it explains why it was worded that way :)
18:18:48 <felixfontein> basically if a module supports everything, there shouldn't be a need to document it
18:19:30 <andersson007_[m]> sounds sensible
18:20:21 <felixfontein> acozine: also for smaller collections, it's annoying if you have to document it everywhere if there's just one module or plugin which is an exception
18:21:17 <gundalow> felixfontein: I know that could happen in theory, do we know if it actually does happen?
18:22:10 <misc> until there is a new version of python
18:22:29 <felixfontein> gundalow: for smaller collections, I'd guess this would happen because one module has another dependency (that requires say Python 3) which the other modules do not need
18:22:39 <misc> (like, I haven't heard of python 4, but given the time between py2 and py1 and py3)
18:23:44 <jillr> misc: don't start that yet, we're still working on getting off of python 2!  :)
18:24:05 <felixfontein> hehe :)
18:24:22 <felixfontein> ok, since this topic is again taking too much time: should we vote on one of the proposals, or postpone this again?
18:24:23 <acozine> so maybe `If everything in your collection supports the same python versions as the current version of ansible-core, you do not need to document python versions. If your collection does not support those python versions, you MUST document which versions it supports in the README. If most of your collection supports the same python versions as ansible-core, but some modules and plugins  do not, you MUST include the supported python versions in the
18:24:23 <acozine> documentation for those modules and plugins.`
18:25:05 <acozine> there are two bits to this topic - one is the policy, and the other is the wording
18:25:09 <jillr> acozine: +1
18:25:16 <acozine> I think we've all agreed on on the policy part
18:25:39 <felixfontein> acozine: sounds good to me
18:25:41 <acozine> "don't make c.g document python versions for everything, do make oddball c.g modules document their supported python versions"
18:26:54 <acozine> plus "generally assume that collections/modules/plugins support the same python versions as ansible-core and don't make that a required documentation field because it would be repetitive and annoying"
18:26:57 <felixfontein> I added acozine's suggestion as a suggestion: https://github.com/ansible-collections/overview/pull/187#discussion_r728340390
18:27:39 <gundalow> I like the idea of separating the vote for policy from wording
18:27:57 <dmsimard> both are hard in different ways :)
18:28:04 <andersson007_[m]> i would split the paragraph by "if"
18:28:10 <andersson007_[m]> felixfontein: ^
18:28:10 <acozine> are there folks arguing for a different policy?
18:28:18 <andersson007_[m]> to make it a bit more readable
18:28:32 <acozine> andersson007_: sounds good
18:28:33 <jillr> yeah it feels like we agree on the policy and just need wording?
18:28:43 <felixfontein> acozine: which one? there are three :)
18:28:49 <tadeboro> What does policy vote brings if we cannot articulate it? I think we just need to spell the policy out.
18:28:56 <andersson007_[m]> felixfontein: all:)
18:29:27 <felixfontein> andersson007_[m]: I think just before the third is fine; I've added it now
18:29:45 <andersson007_[m]> felixfontein: by the second is fine also
18:29:45 <andersson007_[m]> felixfontein: cool:)
18:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:25 <felixfontein> so... is someone not happy with the current version of https://github.com/ansible-collections/overview/pull/187#discussion_r728340390 ?
18:31:24 <dmsimard> felixfontein: by current version of ansible-core do you mean latest version of ansible-core ?
18:31:34 <dmsimard> or a version of ansible-core that is not EOL ?
18:31:41 <acozine> tadeboro: I think the policy is: Require documentation for supported python versions only in 2 cases: in the README if the entire collection supports different python versions; in module/plugin docs if only a few modules/plugins support different python versions. Otherwise, don't document, because the collection and modules/plugins support the same python versions as ansible-core.
18:32:10 <felixfontein> dmsimard: I can change it to `latest`
18:32:53 <dmsimard> felixfontein: sure, it's probably an important distinction
18:33:08 <dmsimard> (especially as we move to >=3.8)
18:33:21 <felixfontein> dmsimard: I personally would mention that it should support the union of all Python versions supported by all ansible-core versions that the collection supports, but I think this will be too confusing :)
18:34:29 <acozine> felixfontein: agreed that `union` would be confusing to translate, unless we used mathematical notation
18:39:11 <felixfontein> ok. I guess we have to stop that topic for today.
18:39:30 <jillr> what are the next steps?  keep iterating in the PR?
18:39:46 <felixfontein> PLEASE add comments to the PR with actual suggestions so we can do something with it before we use it to fill yet another meeting
18:39:59 <acozine> can we vote on the policy? is there still a debate about what the policy should be?
18:40:22 <felixfontein> acozine: if we would have a formulation of the policy, I think we could vote on it
18:41:04 <jillr> I would be ok voting on the formulation of the policy acozine suggested
18:41:25 <acozine> Propsed policy: `Require documentation for supported python versions only in 2 cases: in the README if the entire collection supports different python versions; in module/plugin docs if only a few modules/plugins support different python versions. If the collection and all modules/plugins support the same python versions as ansible-core, do not require documentation of python versions.`
18:41:54 <felixfontein> VOTE: ^
18:41:57 <felixfontein> #chair
18:41:57 <zodbot> Current chairs: acozine andersson007_[m] briantist cidrblock[m] cyberpear dmsimard felixfontein gundalow jillr jtanner tadeboro
18:41:58 <acozine> s/ansible-core/most recent version of ansible-core/g
18:42:01 <cyberpear> +1
18:42:04 <acozine> +1
18:42:05 <felixfontein> +1
18:42:07 <gundalow> +1
18:42:08 <andersson007_[m]> +1
18:42:17 <jillr> +1
18:42:21 <dmsimard> +1
18:42:25 <tadeboro> +1
18:42:52 <cidrblock[m]> +1
18:43:01 <briantist> +1
18:43:31 <Goneri> +1
18:43:45 <felixfontein> #agreed Policy: `Require documentation for supported python versions only in 2 cases: in the README if the entire collection supports different python versions; in module/plugin docs if only a few modules/plugins support different python versions. If the collection and all modules/plugins support the same python versions as ansible-core, do not require documentation of python versions.`
18:43:51 <felixfontein> thanks everyone!
18:43:53 <andersson007_[m]> ?felixfontein: can we for now commit acozine 's suggestion you added?
18:44:03 <acozine> I'll update the docs PR with the suggested wording
18:44:10 <felixfontein> acozine: thanks!
18:44:20 <felixfontein> #topic Deprecation of servicenow.servicenow in favor of servicenow.itsm
18:44:23 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/44
18:44:26 <felixfontein> dmsimard: do you have an update on this one?
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:46:57 <felixfontein> hmm, if not, let's switch to yet another topic :)
18:47:06 <felixfontein> #topic Inclusion candidates for Ansible 5
18:47:06 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/32
18:47:23 <felixfontein> tadeboro: do you want to summarize the current state?
18:47:34 <tadeboro> Sure.
18:48:10 <tadeboro> 1. infoblox.nios_modules is almost ready, needs a second set of eyes.
18:48:33 <tadeboro> 2. netapp.storagegrid has one +1 review, needs a second set of eyes.
18:49:02 <dmsimard> felixfontein: no update beyond what's in the issue for servicenow.servicenow
18:49:06 <tadeboro> 3. vmware.vmware_rest has one +1 review, needs a second set of eyes and depends on inclusion of cloud.common.
18:49:34 <tadeboro> 4. cloud.common is almost ready (needs README update, has two reviews).
18:49:56 <felixfontein> dmsimard: thanks!
18:50:00 <tadeboro> 5. cisco.dnac needs a review. It has one from previous round that is outdated.
18:50:25 <tadeboro> 6. All other candidates have reviews and we are waiting on maintainers to resolve the issues reviewers found.
18:50:46 <tadeboro> So all in all, there is nothing we can vote on today.
18:51:12 <felixfontein> I hope that that will change for next week :)
18:51:22 <tadeboro> But I would kindly ask you: if you have time, please try to review a collection or two so that we can move things forward a bit.
18:51:32 <jillr> tadeboro: I can commit to reviewing netapp.storagegrid
18:51:48 <jillr> I'll be abstaining from vmware and cloud.common though since I submitted them  :)
18:51:55 <felixfontein> the deadline for inclusion is in two weeks, so everything that won't get reviewed and fixed until then has no chance for 5.0.0
18:53:09 <tadeboro> Thank you jillr.
18:53:16 <tadeboro> That is all from my side.
18:53:27 <felixfontein> I'll try to add some review(s) as well, but I'm not sure how many and which ones yet :)
18:53:37 <felixfontein> thanks tadeboro!
18:53:58 <felixfontein> since time's almost up, let's switch to open floor
18:54:01 <felixfontein> #topic Open Floor
18:54:15 <felixfontein> (after all during the last meetings open floor was cut short, so it can have an extra minute today :) )
18:54:34 <felixfontein> is there anything someone wants to discuss that hasn't been up yet?
18:54:40 <felixfontein> (in today's meeting)
18:55:00 <dmsimard> Nothing from me
18:55:19 <andersson007_[m]> dance faster:)
18:55:24 <cyberpear> 🎉 finishing early!
18:55:40 <acozine> that may be a first!
18:55:53 <cidrblock[m]> w00t!
18:55:54 <felixfontein> acozine: it's not, but the last time is quite a while ago ;)
18:56:09 <acozine> heh, you have a good memory felixfontein
18:56:35 <felixfontein> acozine: I still remember that at one of the first meetings a lot of people were away, and we stopped after 20-30 minutes or so ;)
18:56:59 <acozine> wow, we'll never go shorter than that!
18:57:13 <felixfontein> yep, only core meetings are quicker ;)
18:57:33 <felixfontein> (at least the public ones)
18:59:45 <felixfontein> #endmeeting