18:00:02 <felixfontein> #startmeeting Ansible Community Meeting
18:00:02 <zodbot> Meeting started Wed Apr 21 18:00:02 2021 UTC.
18:00:02 <zodbot> This meeting is logged and archived in a public location.
18:00:02 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:02 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:02 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:02 <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!
18:00:06 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:07 * dericcrago waves
18:00:09 <andersson007_> o/
18:00:13 <cybette> o/
18:00:14 <felixfontein> #chair jillr dericcrago andersson007_ tadeboro
18:00:14 <zodbot> Current chairs: andersson007_ dericcrago felixfontein jillr tadeboro
18:00:15 <tadeboro> o/
18:00:20 <felixfontein> #chair cybette
18:00:20 <zodbot> Current chairs: andersson007_ cybette dericcrago felixfontein jillr tadeboro
18:00:20 <samccann> \o
18:00:35 <felixfontein> #chair samccann
18:00:35 <zodbot> Current chairs: andersson007_ cybette dericcrago felixfontein jillr samccann tadeboro
18:00:46 <abadger1999> Greetings and salutations
18:00:49 * lmodemal Lurking today :)
18:00:54 <felixfontein> #chair abadger1999 lmodemal
18:00:54 <zodbot> Current chairs: abadger1999 andersson007_ cybette dericcrago felixfontein jillr lmodemal samccann tadeboro
18:00:58 <cyberpear> o/
18:01:05 <felixfontein> lmodemal: if you prefer not to be furniture, please #unchair yourself :)
18:01:08 <felixfontein> #chair cyberpear
18:01:08 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear cybette dericcrago felixfontein jillr lmodemal samccann tadeboro
18:01:28 <dmsimard> \o/
18:01:33 <felixfontein> #chair dmsimard
18:01:33 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear cybette dericcrago dmsimard felixfontein jillr lmodemal samccann tadeboro
18:01:39 <felixfontein> dmsimard: see my question before the meeting started
18:02:01 <dmsimard> nothing to discuss LTS-wise, I think we settled that we would revisit this in some weeks/months if there is interest
18:02:12 * gundalow waves
18:02:29 <felixfontein> #chair gundalow
18:02:29 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann tadeboro
18:03:03 <lmodemal> #unchair lmodemal
18:03:03 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:03:07 <felixfontein> dmsimard: right. I wonder whether we should have a special label for things that are "for later"
18:03:31 <andersson007_> sounds good
18:03:34 <felixfontein> #topic Updates
18:03:34 <felixfontein> #info Deadline for approval of new collections in Ansible 4 is April 26th, i.e. in 5 days
18:03:37 <felixfontein> #info Deadline for new major releases of collections to be released so they show up in Ansible 4 is also April 26th
18:03:40 <felixfontein> #info community.general and community.network 3.0.0 will be released by then
18:03:52 <cybette> #info The next Ansible Contributor Summit will be held on June 8, 2021 (Tuesday). Please propose topics for the agenda: https://hackmd.io/@ansible-community/contrib-summit-202106
18:04:22 <dericcrago> #info changes to ansible-test units behavior https://github.com/ansible-collections/overview/issues/45#issuecomment-822858320
18:04:48 <felixfontein> cybette: thanks, just added it to my agenda so I won't forget :)
18:05:06 <cybette> felixfontein: great!
18:06:25 <tadeboro> #info Short overview of where the inclusion candidates stand (according to tadeboro, edits welcome): https://github.com/ansible-community/community-topics/issues/10
18:06:42 <felixfontein> tadeboro: I just added that as topic #2 for today ;)
18:06:49 <felixfontein> #topic State of the inclusion candidates for Ansible 4
18:06:49 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/10
18:06:56 <felixfontein> let's do it first then
18:07:08 <felixfontein> I unfortunately haven't managed to look at the candidates again
18:07:53 <andersson007_> tadeboro: thanks for the issue!
18:08:04 <tadeboro> I did go over the candidates today and put my findings into the issue.
18:08:07 <felixfontein> I'll try to look at the ones that you think are ready today though
18:08:09 <abadger1999> Nice summary!
18:08:17 <jillr> I looked somewhat briefly this morning, it seemed like equinix.metal might be ok but we should re-run the check script
18:08:44 <andersson007_> I agree about dell.*
18:08:45 <jillr> otherwise I agree with tadeboro's list
18:08:58 <felixfontein> it's kind of annoying that some collections (like equinix.metal) only started fixing things a few days ago
18:09:13 <tadeboro> I checked the equinix.metal and there was no activity in the repo in the last week, so I assumed things are still bad.
18:09:14 <dmsimard> deadline driven development ? :)
18:09:50 <tadeboro> But as I said in the issue, feel free to edit it if you find things are not as I described them.
18:09:51 <samccann> yeah if it becomes problematic/too much pressure on the team to approve at last minute, maybe we need to adjust the schedule requirements so y'all aren't under undue strain
18:09:57 <felixfontein> dmsimard: the deadline was for being reviewed, not for handing in something that can be reviewed :)
18:09:58 <cyberpear> do we already have any collection related to packet host before they became "Equinix Metal"?
18:10:21 <felixfontein> cybette: some of the modules are in community.general
18:10:23 <felixfontein> argh
18:10:25 <felixfontein> sorry :)
18:10:27 <felixfontein> cyberpear: ^
18:10:27 <cybette> heheh
18:10:30 <andersson007_> I asked exinix  to put a separate comment at the bottom when the collection is ready for review
18:10:52 <tadeboro> cyberpear: I think we do, but no one knows if modules are compatible.
18:10:59 <abadger1999> <nod> If the last-minute collections can't be reviewed by us in time, that's perfectly fine.
18:11:11 <cyberpear> I thought I remembered something about such modules... probably worth bringing up in the review
18:11:12 <felixfontein> cyberpear: https://github.com/ansible-collections/ansible-inclusion/discussions/15#discussioncomment-434496
18:11:25 <cyberpear> ^ even better, already done!
18:11:52 <felixfontein> yeah, except that it took them 1.5 months to reply to that question ;)
18:12:05 <gundalow> If people don't react in time that isn't out fault
18:12:38 <tadeboro> And even after 1 month, they did not manage to determine if API is compatible ;)
18:12:57 <felixfontein> I guess we can all try to take a look at some of the collections, and then we can vote next week... if we have enough positive reviews for a collection and no vetos, I guess it will be lucky, and if there aren't enough positive reviews, then not
18:14:10 <abadger1999> <nod>
18:15:23 <cybette> cyb-clock chimes: 15 min into the meeting
18:15:26 <felixfontein> #info We will try to review collections and decide at the meeting next week which ones will get included
18:15:30 <felixfontein> #topic Licenses for new collections: relax requirements?
18:15:30 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/2
18:15:33 <felixfontein> tadeboro: you added next_meeting to the hpe licensing issue, what do you want to discuss about it? only whether to close it, or something else?
18:15:51 <felixfontein> ah sorry, I wanted to relace the last line, but I forgot :)
18:16:09 <felixfontein> basically tadeboro is suggesting to close this discussion, and we wanted to check if anyone disagrees
18:16:52 <tadeboro> I just want to make sure we all agree that HPE changing the doc fragment license to GPLv3 makes them compliant with the licensing rules we set.
18:17:38 <abadger1999> I think yes.
18:17:55 <felixfontein> it looks good to me. Apache is fine for module_utils and modules
18:18:37 <felixfontein> VOTE: is Apache 2.0 license for modules and module_utils, and GPL for everything else ok for hpe.nimble?
18:18:40 <felixfontein> +1
18:18:54 <andersson007_> +1
18:18:57 <jillr> +1
18:18:59 <tadeboro> +1
18:19:05 <abadger1999> +1
18:19:10 <samccann> abstaining due to general license ignorance
18:19:10 <felixfontein> (basically voting +1 means "close the issue" :) )
18:19:12 <cybette> +1
18:19:17 <gundalow> +1
18:19:48 <tadeboro> For reference: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#licensing is the relevant part of the requirements.
18:20:11 <felixfontein> #info https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#licensing is the relevant part of the requirements
18:21:28 <felixfontein> #agreed Apache 2.0 license for modules and module_utils, and GPL for everything else is ok for hpe.nimble
18:22:08 <felixfontein> tadeboro: do you want the honor to close the issue? :)
18:22:23 <tadeboro> Done.
18:22:26 <felixfontein> +1
18:22:28 <felixfontein> #topic Remove Python 2.6 requirement
18:22:28 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/6
18:22:31 <felixfontein> #info Proposal: https://github.com/ansible-collections/overview/pull/165
18:22:32 <github-linkbot> https://github.com/ansible-collections/overview/pull/165 | open, created 2021-04-07T16:50:26Z by abadger: RHEL6 went EOL on November 30, 2020.
18:22:42 <felixfontein> abadger1999 updated his proposal with what we discussed last week (IIRC)
18:22:51 <abadger1999> Yep :-)
18:23:16 <abadger1999> Does it look good to people or would you all like more changes?
18:23:28 <felixfontein> I'm happt with the current version
18:23:56 <abadger1999> https://github.com/ansible-collections/overview/pull/165/files
18:24:25 <jillr> ship it
18:24:25 <samccann> LGTM
18:24:37 <abadger1999> samccann: I still need to get together with you to figure out where in the docs.ansible.com pages to document this for end users too, but we can figure that out after the meeting.
18:24:38 <dericcrago> +1
18:24:46 <tadeboro> I have nothing to add. And during reviews, I did not make a fuss at all if collection does not support 2.6 (as long as they state somewhere Ptython >= 2.7 for example).
18:24:50 <felixfontein> VOTE: should we merge https://github.com/ansible-collections/overview/pull/165/files as-is?
18:24:50 <samccann> sounds good
18:24:53 <abadger1999> +1
18:24:55 <tadeboro> +1
18:24:57 <samccann> +1
18:24:59 <jillr> +1
18:25:06 <andersson007_> +1
18:25:17 <cybette> +1
18:27:22 <felixfontein> #agreed we merge https://github.com/ansible-collections/overview/pull/165/files as-is
18:27:25 <felixfontein> great :)
18:27:49 * abadger1999 merges and closes the meeting ticket
18:28:00 <felixfontein> sorry, already merged it ;)
18:28:04 <abadger1999> heh, /me is too slow ;-)
18:28:42 <felixfontein> ok. should we re-start the 'new content for c.g/c.n' discussion, or does anyone have something else to discuss before that?
18:29:39 <felixfontein> alternatively, we could also stop the meeting early and start going through the collection inclusion applications, if someone is interested in that (and has time :) )
18:29:42 <abadger1999> Nothing from me
18:30:08 <felixfontein> (that would be a **really** short community meeting :) )
18:30:21 <samccann> heh
18:31:12 <cybette> cyb-clock chimes 30 min past the hour, and wonders if we're going to break the record for shortest meeting
18:31:33 * andersson007_ thinks the new content in c.g c.n would be a hot and long discussion
18:32:04 <felixfontein> andersson007_: yes, and everyone needs to refresh their memory since the first part of that discussion happened last year ;)
18:32:25 <abadger1999> Heh
18:32:31 <andersson007_> felixfontein: let's maybe do it next time:)
18:32:39 <tadeboro> How much new content is waiting for our decision? If there is a non-trivial amount of it, maybe we should start discussing this.
18:32:57 <felixfontein> andersson007_: then in two weeks, since next week we have to decide on which collections to actually include ;)
18:33:19 <andersson007_> felixfontein: sounds good
18:33:29 <andersson007_> enough time to refresh knoledge
18:33:33 <felixfontein> tadeboro: do you mean content for c.g/c.n? I don't think anything is waiting for a discussion, stuff gets added until we decide to no longer add stuff ;)
18:34:01 <tadeboro> felixfontein: Then schedule discussion for 2025 ;)
18:34:06 <felixfontein> hehe :D
18:34:25 <felixfontein> actually here's a module PR I'm not sure whether we should include it: https://github.com/ansible-collections/community.general/pull/2213
18:34:25 <github-linkbot> https://github.com/ansible-collections/community.general/pull/2213 | open, created 2021-04-09T08:41:12Z by saranyasridharan: Module to get disk information [affects_2.10,ci_verified,integration,module,needs_revision,new_contributor,new_module,new_plugin,plugins,system,tests,unit]
18:34:27 <tadeboro> I am OK with waiting if we are not loosing potential contributors.
18:34:38 <abadger1999> tadeboro: :-)
18:35:12 <andersson007_> tadeboro: we are definitely not:)
18:35:26 <felixfontein> I think a lot of stuff in c.n is waiting for reviews. if someone is bored (and knows stuff about network modules)... ;)
18:36:39 <abadger1999> Hmm... that one looks like it's duplicating functionality for retrieving data and the question is whether the difference in presentation justifies its inclusion?
18:37:47 <aminvakil> i don't think so IMHO
18:38:01 <samccann> what I can't judge - does this new module make it EASIER for the end user vs the `setup` module?
18:38:33 <felixfontein> abadger1999: pretty much... I'm not 100% sure if it doesn't offer some things that setup doesn't offer right now, at least with the latest changes (which broke tests)
18:38:41 <samccann> my eyes glazed over when trying to understand the comments about how to do this with `setup` and/or filters etc
18:38:51 * acozine is back from the dentist at last
18:38:58 <felixfontein> #chair acozine
18:38:58 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:39:05 <abadger1999> samccann: My initial thought would be yes, it does make it easier.  having to chain together more than two filters is probably difficult for end users.
18:39:06 <felixfontein> acozine: from one chair to the next... :)
18:39:13 <acozine> heh, yep
18:39:17 <acozine> this one is way more comfy
18:39:23 <felixfontein> definitely!
18:39:41 <cybette> should we change the meeting topic?
18:39:46 <samccann> my nickel, without knowing full details, is - if it's much easier for an average (aka not expert) ansible user to use the new module, it may be worth the duplication
18:39:57 <felixfontein> abadger1999: maybe providing more filters would solve that problem :)
18:40:16 <felixfontein> I thought we had a PR for such a filter (or even merged it?) but couldn't find it when looking for it
18:40:17 <abadger1999> #topic Should we include a disk_facts module into community.general:  https://github.com/ansible-collections/community.general/pull/2213
18:40:27 <felixfontein> cybette: good idea :)
18:40:37 <felixfontein> it's now an _info module btw :)
18:40:38 <cybette> :)
18:41:17 <felixfontein> ah wait, that was a different kind of plugin
18:41:36 <felixfontein> having something like groupby which does not return a dict with lists, but simply a dict would be nice
18:41:45 <felixfontein> (or does that already exist?)
18:41:59 <felixfontein> because that would allow to convert the result of setup to something equivalent to the result of this module
18:42:05 <russoz[m]> morning all - I don't claim to be fully awaken yet, but keeping an eye on things :-)
18:42:22 <abadger1999> samccann: I think I've always leaned towards your way of thinking and usually been outvoted on the core team.  Since this is about community.general, I'm not bound to stick with precedent now ;-)
18:42:27 <felixfontein> #chair russoz[m]
18:42:27 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr russoz[m] samccann tadeboro
18:43:28 <felixfontein> for me it depends on how often people actually need this functionality
18:43:38 <aminvakil> felixfontein: +1
18:43:40 <samccann> is the average ansible user going to be familiar enough with a groupby kind of functionality on the setup module etc?
18:43:49 <felixfontein> if it is something you need once your life, I don't think adding a convenience module to make life a bit simpler in that moment is worth it
18:43:54 <acozine> I have an uncomfortable feeling about opening these particular floodgates
18:43:59 <felixfontein> :)
18:44:16 <samccann> which floodgates acozine?
18:44:18 <acozine> because "no duplicate functionality" is an easy policy to express, and to enforce
18:44:38 <samccann> true, but it also closes the gate entirely on making ansible easier to use
18:44:47 <acozine> but "well, if it's useful to enough people, duplication is okay" is much harder to measure, discuss, and apply
18:45:13 <acozine> yeah, I guess it depends on whether we think tons of people will make mini-modules that duplicate existing core functionality
18:45:16 <felixfontein> indeed
18:45:25 <aminvakil> samccann: i'm an average ansible user, but if i ever wanted the same output this module prints, i would change setup module to acquire them, as i don't think ansible has another module with same functionality which prints what i need
18:45:38 <cybette> cyb-clock chimes: 45 min into the meeting, discussing the disk_info module for community.general
18:45:43 <abadger1999> I'm definitely pro  opening that particular floodgate for the ansible tarball but I can see the utility of having a no duplicate policy within a collection.  OTOH, community.general does not contain the setup module.
18:45:51 <acozine> I do kinda like this module, it seems easy to use and beginner-friendly
18:46:03 <felixfontein> I think something more specialized than the existing groupby (https://jinja.palletsprojects.com/en/2.11.x/templates/#groupby) would be useful in general, I think I had the situation more than once where I wanted to convert a list of dicts to a dict of dicts based on an attribute in the inner dicts
18:46:35 <felixfontein> but we can of course also have this module *and* an extended groupby filter :)
18:46:40 <acozine> and if we're not worried about a flood of "I'd rather use this module I wrote than the standard ansible way" leading to hundreds of new modules, then I'm fine with it
18:46:51 <samccann> aminvakil - would you want this new module then? or do you see it as unnecessary duplication, even if it's a bit easier to use?
18:47:11 <aminvakil> i think it's an unnecessary duplication imho, sorry if i wasn't clear enough
18:47:27 <samccann> thanks aminvakil - thought that was what you were saying but wanted to be clear
18:47:50 <gundalow> "I'd rather use this module I wrote than the standard ansible way"
18:47:50 <gundalow> That's a concern for me
18:48:20 <samccann> so if the average user can just use the setup command with some filtering, maybe the solution is to add the appropriate examples from the comments in this PR to the setup module itself, and reject this new module?
18:48:36 <samccann> aka solve it with docs :-)
18:49:09 <abadger1999> heh... test: gundalow, dericcrago, dmsimard : could any of you have come up with the filter chain that felixfontein posted in the PR?
18:49:30 <felixfontein> samccann: one problem is that the one example needs a filter from c.g, which I don't think ansible-core docs want to mention in core modules examples :)
18:49:53 * dmsimard looks
18:49:54 <samccann> sigh
18:49:56 <acozine> I do think this case is worth the duplication, because the standard ansible way is hard
18:50:28 <felixfontein> I actually first tried `| groupby | c.g.dict`, but then I couldn't get rid of the lists in the values...
18:50:29 <acozine> at the same time I worry about how we create a measurement for future requests
18:50:41 <acozine> maybe that is borrowing trouble
18:51:21 <jillr> I'd lean towards accepting it, on the idea that the standard way is harder and collections kind of exist to augment core functionality, which this seems to do
18:51:23 <samccann> this module is only being questioned because it's adding to c.g right? if it was in my_spiffy_collection, I could do what I wanted?
18:51:54 <felixfontein> samccann: yes. my_spiffy_collection isn't included in Ansible though :)
18:51:55 <abadger1999> <nod> So it does seem like if our bar is average user, then this could be on the "too difficult" end of the spectrum.
18:51:59 <samccann> aka the way to measure future requests to collections we maintain is just what we do here - bring it up, vote on it.
18:52:02 <acozine> how many PRs have we had so far that wanted to add a new module to c.g?
18:52:07 <jillr> samccann: yeah, and I feel like we're trying decide how (or if) to apply core acceptance criteria to c.g
18:52:10 <dmsimard> abadger1999: I'm not a heavy user of data manipulation with lots of chained filters, probably not the right audience -- I tend to fall back to multi-line jinja statements or python if it gets too complicated
18:52:38 <felixfontein> acozine: quite a few. not every made it to the end (authors give up for various reasons), most get merged though eventually I think
18:52:44 <abadger1999> samccann: I would definitely vote to allow if it was in my_spiffy_collection (even if my_spiffy_collection is in the ansible tarball)
18:53:33 <gundalow> abadger1999: not by myself, though I haven't ever had the need to do much with filters before
18:53:37 <samccann> yeah so as jillr said - the decision seems to be - does c.g hold to core requirements for zero duplication, or does c.g (and any other collection we manage) decide differently
18:53:43 <acozine> perhaps we could/should track the number of modules in/out of c.g and agree that we'd revisit if it got over a certain number?
18:53:47 <abadger1999> dmsimard: I think you're exactly the right audience.... ie: I doubt that most of our usrs are heavy users of data manipulation.  So if it's difficult for you, it would probably be just as difficult for the average user.
18:54:16 <acozine> revisit the question of how hard we try to eliminate duplication, I mean
18:54:32 <abadger1999> <nod>
18:54:37 <samccann> I'm +1 for allowing improvements based on making Ansible easier for 'average' users vs filter/data manipulation expert users
18:54:45 <dmsimard> FWIW I discovered these docs about "complex data manipulation": https://docs.ansible.com/ansible/latest/user_guide/complex_data_manipulation.html
18:55:02 <felixfontein> right now it looks to me like more people are in favor of including this than not including it
18:55:03 <andersson007_> samccann: +1
18:55:36 <felixfontein> (it all depends on whether they fix the issues their latest commit introduced of course, it definintely can't be merged in the current state :) )
18:55:52 <andersson007_> :)
18:55:55 <acozine> +1 . . . and let's start measuring the flow of modules into/out of c.g so we have an idea of whether this is a problem
18:56:18 <abadger1999> samccann: +1
18:56:19 <felixfontein> it looks like the highlighted lines in that document are off
18:56:51 <abadger1999> felixfontein: agreed that htey still have to fiix the problems that have been pointed out
18:56:58 <felixfontein> acozine: right now, almost nothing is moving out of c.g anymore... if the infoblox collection would get included we could transfer a bunch of modules, but they don't seem to make it
18:57:23 <tadeboro> I am +0 on this topic (usually, I think composition > custom stuff and tend to go the "document things better" way, but since I am not the collection maintainer, I have no strong feelings here).
18:57:53 <sivel> felixfontein: we've had a number of pages with that happen to. People update the docs to improve formatting (or what they think are improvements) and not update the line numbers
18:58:26 <acozine> felixfontein: sivel we merged a PR to fix those yesterday
18:58:34 <acozine> just need to backport and publish
18:58:39 <felixfontein> ah ok :)
18:58:49 <russoz[m]> +0 here as well - mixed feelings on that
18:58:54 <dericcrago> abadger1999 - given enough time, sure, but I don't think the right approach is to expect everyone who comes across this problem spend X amount time figuring it out uniquely vs including a shortcut for folks
18:59:20 <bcoca> a role is also a valid way to share the solution
18:59:24 <felixfontein> should we vote on whether we want to include the module in c.g (assuming it passes the 'regular' review, i.e. code looks good and tests pass)?
18:59:29 <bcoca> just has vars/main with the transformations
18:59:57 <samccann> felixfontein yeah seems opinions are differing now, so a baseline vote would help clarify
19:00:22 <acozine> this use case is hard to document, because we cannot document every single specific thing you could retrieve from ansible facts, and reading docs about filters and data manipulation is much harder than reading module docs
19:00:44 <acozine> felixfontein: yeah, let's vote
19:00:45 <felixfontein> VOTE: do we want to include the disk_info (https://github.com/ansible-collections/community.general/pull/2213) in community.general, assuming it passes the regular review (code looks good, tests pass)?
19:00:45 <github-linkbot> https://github.com/ansible-collections/community.general/pull/2213) | open, created 2021-04-09T08:41:12Z by saranyasridharan: Module to get disk information [affects_2.10,ci_verified,integration,module,needs_revision,new_contributor,new_module,new_plugin,plugins,system,tests,unit]
19:00:50 <cybette> cyb-clock chimes: 1 HOUR into the meeting, and around 25 min on the disk_info module
19:00:51 <sivel> -1
19:00:52 <felixfontein> #chair
19:00:52 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr russoz[m] samccann tadeboro
19:00:58 <gundalow> +0
19:01:04 <russoz[m]> +0
19:01:04 <abadger1999> +1
19:01:05 <bcoca> i agree module is easier foruser, i would ask, how many users need this specifc structure?
19:01:07 <felixfontein> +0
19:01:07 <andersson007_> +1
19:01:12 <cyberpear> +0
19:01:12 <samccann> +1
19:01:14 <aminvakil> -1
19:01:20 <jillr> +0.5 (but I don't have to maintain it, so it's a soft preference)
19:01:25 <samccann> lol
19:01:31 <tadeboro> +0 (leaning towards -1)
19:01:45 <cybette> +0
19:01:45 <acozine> +1
19:01:50 <dmsimard> -0
19:02:07 <samccann> omgosh the creative shades of grey here in the voting!!!
19:02:22 <bcoca> -i
19:02:25 <dericcrago> +1
19:02:27 <samccann> heh
19:02:28 <acozine> it's like muons . . . some of the zeros are just slightly heavier than others
19:02:32 <jillr> we could flip a coin?  (j/k)
19:02:46 <felixfontein> (I think I'll definitely create a PR for a new filter which makes it easier to transform the setup output into this form; I think that will be more useful to more users in more situations :) )
19:03:19 <samccann> that still leaves us with - we can't document how to do this with setup within the setup module itself
19:03:21 <bcoca> felixfontein: my point stills tands, is this new format that much mroe usefull?
19:03:35 <samccann> maybe we can document it 'somewhere' and add that link as a seealso to the setup module?
19:03:53 <abadger1999> I think this is close enough that we're going to need to have to record steering committee member votes and ask the non-present members of the steering committee to vote as well.
19:03:57 <bcoca> samccann:  i would argue that data transformations for every module that returns facts would end up in an infinite exampl;es list
19:04:08 <bcoca> do you NEED to document every possible transformation?
19:04:23 <felixfontein> bcoca: I'm not sure in this specific situation - but I'm sure that such a transform in general is useful, since I encountered such situations myself already where I would have liked to have that :)
19:04:25 <bcoca> is this transformation that useful? is it needed by many or just by author?
19:04:55 <bcoca> felixfontein: why i started data manipulation, its a bit generic but helps with these kinds of things, if it s a one off, i dont thinkg its worth it
19:04:56 <gundalow> Do we need a page with lots of realworld transformations (rather than foo | bar) ?
19:04:56 <felixfontein> I think the most useful part of this module is that you can quickly get the information for one specific disk
19:05:14 <jillr> gundalow: +1
19:05:16 <samccann> so when I read the description of this new module, I'm left with a feeling like - this person is managing multiple OS's, found the win_disk_facts module easy to use and wanted something similar for linux
19:05:17 <bcoca> if its a common format a significant set of user base wants, def documenet/create module/filter
19:05:19 * sivel runs away very quickly and goes back to ignoring community.general
19:05:26 <felixfontein> which requires `| selectattr() | first` for setup output, and `['/dev/sda']` for this module
19:05:32 <bcoca> gundalow: data manipulation is such a page
19:05:32 <acozine> I think the biggest advantage of this is that someone searching for "ansible get disk info" would get this page
19:05:35 <samccann> gundalow+1
19:06:04 <jillr> we see these come up as specific needs that might be widely shared, but the common thread is transformations are hard
19:06:08 <bcoca> acozine: you still get the disk info from setup, just not in the format this user needed
19:06:09 <jillr> *that might not be
19:06:26 <acozine> whereas that search is unlikely to return either the setup module or the data manipulation page
19:06:33 <bcoca> i agree, trasnformations are hard, but a module per transformation possible is also not an answer
19:06:53 <acozine> bcoca: yeah, that's why we were discussing whether this would become a trend
19:06:53 <bcoca> for 'commonly used' transformations, i would make a case
19:06:56 <samccann> yeah but if we had a document that covered this with real world examples, that could have a heading 'get disk information from multiple operating systems with Ansible'
19:06:57 <jillr> bcoca: right, I was saying it to gundalow's point about more real world examples in docs
19:06:58 <russoz[m]> so what would tre answer be then?
19:07:04 <russoz[m]> *the
19:07:09 <felixfontein> it might be more useful to have the module return information on precisely one disk, then it's even easier to use in that use-case
19:07:19 <bcoca> jillr: i started a page, feel free to add anytime you come across something you think is reusable
19:07:32 <bcoca> https://docs.ansible.com/ansible/latest/user_guide/complex_data_manipulation.html
19:07:49 <bcoca> ^ uses REAL world examples we came across
19:08:52 <bcoca> even better, a step by step explanation of what the filter chain is
19:10:11 <acozine> maybe we should retitle your page "How the #@%* do I get this piece of data out of all that JSON?"
19:10:13 <russoz[m]> so now we know who's off with the highlighted lines :P
19:10:26 <gundalow> acozine: That would be good for SEO :)
19:10:28 <jillr> acozine: +1
19:10:32 <samccann> heh maybe we need the sysadmin's guide to using Ansible, and pick the top 20 tasks an admin does, and write the use cases, complete with whatever filters/manipulations are necessary
19:10:36 <bcoca> acozine: i thought that was rejected! ... ill resubmit!
19:10:55 <acozine> heh
19:10:57 <felixfontein> abadger1999: even when restricting the above vote to steering committee members, the result isn't a clear decision... there are too many 0s :)
19:10:59 <tadeboro> I still preffer basic components + instructions on how to compose them. But I also like Haskell, soooo yeah ;)
19:11:10 <bcoca> russoz[m]: i submitted fix, people update w/o realizing highlights
19:11:10 <jillr> lol
19:11:19 <gundalow> ooooooooooooooook
19:11:19 <abadger1999> felixfontein: Right... we'll need to ask the non-present members to vote too.
19:11:27 <gundalow> So where are we going with this
19:11:27 <russoz[m]> :)
19:11:28 <felixfontein> tadeboro: yeah, people with (functional) programming background prefer that :)
19:11:30 <gundalow> ah, gw Mr Badger
19:11:44 <resmo> o/ late to the party
19:11:50 <abadger1999> We don't have enough +/- here today to definitively tell what the outcome will be.
19:11:56 <gundalow> #chair resmo
19:11:56 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr resmo russoz[m] samccann tadeboro
19:11:58 <felixfontein> I guess we'll table the discussion for today, since we obviouly won't reach a consensus (neither one for accepting nor one for rejecting)
19:12:04 <felixfontein> hi resmo!
19:12:05 <acozine> maybe we should make it a race
19:12:21 <samccann> the first to write a docs PR to cover this wins?
19:12:25 <acozine> if we create docs everyone loves before the PR passes, we reject it
19:12:27 <samccann> ;-)
19:12:31 <acozine> if the PR passes first, we merge
19:12:34 <abadger1999> felixfontein: So we want to tally the vote and then ask the other steering committee members to vote in the ticket or do we want to have more discussion next week?
19:12:42 <felixfontein> I'll create a discussion issue for it, then we can discuss it next week
19:12:47 <felixfontein> ah
19:12:49 <abadger1999> Cool.
19:12:57 <abadger1999> s/So we/Do we/
19:13:04 <samccann> yeah someplace for steering peeps to understand the issue and comment in case they can't make the next meeting?
19:13:09 <felixfontein> I'm fine with discussing it next week, but we can of course also do a vote until next week. whatever you all prefer :)
19:13:17 <abadger1999> I'm fine either wya.
19:13:34 <acozine> can someone gather a few stats on number of modules in c.g over time, and how many duplicate existing functionality?
19:13:41 <acozine> before we discuss again?
19:13:43 <felixfontein> then let's discuss next week, once we're through with the collection inclusions
19:13:44 <acozine> or vote again?
19:13:56 <bcoca> acozine: i don tthink duplication is a big issue, relevance for me is more of an issue
19:14:10 <acozine> felixfontein: +1
19:14:11 <felixfontein> acozine: I don't think we had really duplicate functionality so far... at least none I noticed
19:14:17 <bcoca> we will always have some overlap, but 'is it worth it' is the big question, how many people will need this specific structure?
19:14:32 <felixfontein> acozine: the only duplicate functionality was 'new module for new version of API since differences are too big', but that's not really a duplication IMO
19:14:45 <felixfontein> good
19:15:02 <felixfontein> #action felixfontein create discussion issue for this so we can discuss again next week
19:15:04 <bcoca> felixfontein: duplicate as in it gathers the data already gathered by other .. not same structure
19:15:17 <cybette> cyb-clock chimes: 1 hr 15 min into the meeting, and around 40 min on the disk_info module
19:15:33 <felixfontein> #topic open floor
19:15:59 <felixfontein> bcoca: that's included in what I meant :)
19:16:30 <bcoca> sorry, had inferred differently
19:16:30 <felixfontein> (you could also say that disk_info is already covered by the shell module ;) )
19:16:35 <bcoca> he
19:16:52 <bcoca> well, shell/command/raw/script are there as fallbacks, they dupe 'everything'
19:18:08 <felixfontein> does anyone have topics for the open floor?
19:21:35 <gundalow> So i can close all PRs that aren't for shell/command/raw/script. Backlog solved everybody
19:21:47 <acozine> heh
19:22:06 <felixfontein> \o/
19:22:50 <aminvakil> :)
19:22:58 <gundalow> Nothing else from me
19:25:32 <felixfontein> #endmeeting