13:43:20 <acozine> #startmeeting Hackathon Day Two
13:43:20 <zodbot> Meeting started Wed Jul  8 13:43:20 2020 UTC.
13:43:20 <zodbot> This meeting is logged and archived in a public location.
13:43:20 <zodbot> The chair is acozine. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:43:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:43:20 <zodbot> The meeting name has been set to 'hackathon_day_two'
13:43:51 <acozine> welcome to the second day of the Ansible Community Hackathon
13:44:04 <acozine> we'll spend at least part of today on docs issues
13:44:04 <gundalow> woot woot
13:44:32 <acozine> who is around?
13:44:37 * gundalow waves
13:44:47 <acozine> #chair baptistemm gundalow samccann
13:44:47 <zodbot> Current chairs: acozine baptistemm gundalow samccann
13:45:19 <acozine> we have a bunch of tidying to do on module docs in collections
13:45:35 <gundalow> Excellent
13:47:22 * acozine digs around for links
13:48:47 <acozine> in 2.9, we had excellent cross-references in the `seealso` sections - for example https://docs.ansible.com/ansible/latest/modules/postgresql_copy_module.html#see-also
13:49:10 <felixfontein> we still have these
13:49:23 <acozine> felixfontein hi!
13:49:28 <acozine> #chair felixfontein
13:49:28 <zodbot> Current chairs: acozine baptistemm felixfontein gundalow samccann
13:49:43 <acozine> yes, we still have them, but with the collections migration, they need to use FQCN
13:51:08 * acozine digs up PR
13:51:13 * baptistemm did not finish to read the backlog (and irssi crashed) while I had an insomnia and read a lot
13:52:54 <acozine> baptistemm: I have no backlog at all today
13:53:10 <acozine> but we did post a log from yesterday . . .
13:53:12 <acozine> um . . .
13:53:27 <acozine> Docs hackathon actions: https://meetbot.fedoraproject.org/ansible-docs/2020-07-07/ansible_docs_hackathon.2020-07-07-14.05.html
13:53:27 <acozine> Docs hackathon full log: https://meetbot.fedoraproject.org/ansible-docs/2020-07-07/ansible_docs_hackathon.2020-07-07-14.05.log.html
13:53:42 <acozine> (thanks gundalow!)
13:54:17 <acozine> here's the PR that enabled M(...) and `seealso` in module docs for the new pipeline
13:54:19 <acozine> https://github.com/ansible-community/antsibull/pull/92
13:55:02 <baptistemm> M() is for Module ?
13:55:58 <acozine> baptistemm yes, the `M()` syntax makes a link to another module within the text of the DOCUMENTATION
13:56:32 <acozine> the `seealso` syntax creates a box with one or more links to other modules
13:56:40 <acozine> at the bottom of the DOCUMENTATION section
13:57:47 <acozine> in the new collections ecosystem, those links need to provide the FQCN for the module they link to
13:59:55 <acozine> here's a gist showing those modules from 2.9:
13:59:57 <acozine> https://gist.github.com/acozine/052a6f966f377b662b8e8eaaa70e2c3e
14:01:07 <acozine> so we could create issues in the relevant collections, or just open PRs to update those links to use FQCN
14:01:16 <acozine> (or both, of course)
14:02:09 <acozine> I'll do a list of M() instances in a minute
14:02:48 <samccann> so maybe what we can do is run that grep cmd against individual collections and then either open an issue w/ the list , or if it's short and we feel inspired, open the PR directly?
14:03:02 <samccann> (as in would that grep work just as well per collection?)
14:03:24 <acozine> yes, it would catch any new `seealso` sections that have been added
14:03:55 <acozine> that list from 2.9 is a good starting point
14:04:01 <acozine> but there might be more
14:04:21 * acozine has a small home distraction, AFK 5
14:05:11 <samccann> ok so while she's off a bit - there is also a script that the network team created to do a batch of cleanup on their collectoins.
14:05:23 <gundalow> Issue per repo with a list of things to fix would be good
14:05:24 <samccann> some of that I think fixed the M() for sure
14:05:50 <gundalow> samccann: oh, cool, if there is a list of things network team has had to fix up that would be cool, maybe dump in the Etherpad for the moment
14:06:03 <gundalow> I also need to drop for other meetings, I'll keep an eye on IRC
14:06:06 <samccann> the link is in the etherpad already
14:06:20 <baptistemm> if you have some example commit, I can help doing PRs
14:06:29 <samccann> for the script. I can ask them for what all it fixes besides a few docs things
14:06:45 <samccann> #actoin samccann to delve into what network team script fixes
14:06:52 <samccann> omgosh cannot spell today!
14:07:08 <samccann> #action samccann to delv into what network team script fixes
14:07:24 <samccann> hmm.  dunno if that's working or not
14:07:42 <samccann> anyway baptistemm : thanks!  that will help for sure
14:09:01 * samccann digs up link to script
14:09:56 <samccann> #link https://github.com/ansible-network/collection_prep
14:10:31 <samccann> so that has multiple scripts for cleaning up a collection. add_docs.py is one I don't expect most collections to use
14:11:05 <samccann> that one I think adds .rst files from all the collection docstrings because their collections released before 2.10. By 2.10 we'll have module docs back up on docs.ansible.com
14:12:28 * acozine back
14:13:10 <samccann> so to finish up the script talk - would love it if someone could review and maybe fork it to create more general scripts for collection owners to use
14:13:36 <samccann> #info need someone to generalize those scripts to make them available to all collection owners for general pre-release cleanup steps
14:15:24 <acozine> I added a second file to the gist, showing which modules in 2.9 used the `M()` syntax
14:15:46 <acozine> https://gist.github.com/acozine/052a6f966f377b662b8e8eaaa70e2c3e
14:16:05 <samccann> #link https://gist.github.com/acozine/052a6f966f377b662b8e8eaaa70e2c3e
14:16:22 <samccann> #info includes M() and :seealso: from 2.9 for reference.
14:17:05 <acozine> again, other modules in more collections may have that now, but the ones in that gist form a good starting point
14:17:25 <samccann> #info run that grep against individual collections and open an Issue with the list of items the collection team needs to fix
14:18:00 <samccann> is there anything we can do right now toward that goal?
14:18:12 <samccann> to add the 'hack' to hackathon :-)
14:19:38 <acozine> sure - clone a collection, search through it (grep or editor) for seealso and M(), update those with FQCNs, open a PR, post the PR here for review
14:20:05 <acozine> or open an issue with a list of modules that need fixing, post the issue here
14:21:21 <baptistemm> perhaps people should tell which one they working on ?
14:21:27 <baptistemm> to avoid collision
14:21:32 <samccann> ok I'm going to grab community.network
14:21:41 <acozine> baptistemm yes, good idea
14:21:55 <baptistemm> etherpad is good also
14:22:00 <baptistemm> whateer fits
14:22:01 <acozine> baptistemm thanks for catching that typo on PR 70488!
14:22:07 <baptistemm> I cannot work now but plan later in the day
14:22:33 <acozine> baptistemm awesome, thanks!
14:22:42 <baptistemm> acozine: did my duty at 4:00 AM
14:23:20 <acozine> ah, well, thanks for putting your insomnia to good use
14:23:25 <acozine> hope you get better sleep tonight!
14:23:37 <baptistemm> blame mosquitos
14:23:55 <baptistemm> arrived for 3 days and I'm up at 4:00 AM since then
14:24:07 <acozine> ugh, that sounds awful
14:24:15 <baptistemm> s/blame/thanks/
14:24:21 <acozine> heh
14:24:58 <baptistemm> not that awful, but instead of hitting myself to squizz them I go downstairs and read the internet
14:28:35 <acozine> that's very productive of you baptistemm
14:32:18 * baptistemm would like to make its ansible code by now ...
14:32:25 <baptistemm> +works
14:40:06 <samccann> sorry in another meeting so multitasking but this is the first issue - https://github.com/ansible-collections/community.network/issues/86
14:40:14 <samccann> let me know if I should have more detail there or not
14:49:12 <samccann> ok going to move onto community.general now
14:50:52 <acozine> woot! Thanks samccann
14:58:06 <acozine> I'll do community.crypto
15:02:09 <felixfontein> what are you planning to do in community.crypto?
15:02:12 <felixfontein> acozine:
15:02:34 <acozine> felixfontein create an issue for which modules have seealso and M() references
15:02:36 <felixfontein> FQCNs in references are already there (thanks to abadger)
15:02:44 <acozine> ohhh, okay
15:02:45 <felixfontein> he updated both M(...) and seealso some time ago
15:02:48 <acozine> heh
15:02:56 <samccann> just created the issue for community.general - https://github.com/ansible-collections/community.general/issues/632
15:02:56 <felixfontein> feel free to look again, but I think all have been fixed :)
15:02:58 <acozine> so I need to be more sophisticated in how I search
15:03:09 <samccann> i feel like maybe I should move the full list down to a comment? seems... long
15:03:28 <samccann> I can check community.crypto next if you want
15:03:31 <felixfontein> I think M(...) and seealso have already been fixed in c.g and c.n as well
15:03:49 <samccann> hmm. maybe I'm doing something wrong then. the list was huge
15:04:04 <samccann> but maybe the grep assumes all M(..) have not been fixed and we're doing this wrong
15:04:05 <felixfontein> it's still called M(...) :)
15:04:18 <felixfontein> the grep simply finds all `M(`
15:04:20 <samccann> sigh. At least I started w. your two collections...
15:04:41 <samccann> anyone got a clever way to check whether it's all been updated or not? grep magic isn't my strong point
15:04:42 <acozine> yeah, sorry, I forgot that some had already been fixed
15:04:54 <felixfontein> andersson007 fixed all the seealsos, and I think I fixed the M(...)s manually
15:05:07 <felixfontein> the only things that aren't fixed in c.g and c.n are FQCNs in examples
15:05:31 <samccann> Those scripts I pointed to in the issue fix that as well. just not sure which one or which part
15:05:34 <felixfontein> no problem, just saw that you're working on this and wanted to warn you before you spent more time on it for these collections :)
15:05:37 <samccann> (fixes FQCN)
15:06:02 <felixfontein> that would be useful
15:06:13 <samccann> so is there a clever grep that would check for M( that does NOT start with community.general?
15:07:22 <acozine> hrm, even that wouldn't work
15:07:40 <acozine> because M( can refer to modules in another collection
15:07:41 <felixfontein> I guess there is, but you'd need advanced regex. Essentially grep for `M\([^.)]+\)`
15:07:52 <acozine> yeah, that would work
15:08:01 <felixfontein> with the correct options; maybe `grep -ER 'M\([^.)]+\)' .` will do the trick
15:08:05 <acozine> "find me anything that starts with M( and doesn't have a period in it"
15:08:16 <acozine> no period == no collection name
15:08:24 <felixfontein> exactly
15:08:55 <acozine> I can read regex, sort of, i just can't write it without a "dictionary" at hand
15:10:02 <samccann> ok I'll try that thanks
15:10:20 <gundalow> felixfontein: did andersson007 have a script to fix these?
15:12:26 <acozine> I just checked community.aws, the M( refs have already been fixed there
15:12:43 <acozine> no seealso in the modules there
15:13:39 <samccann> hmm...  grep -ER 'M\([^.)]+\'
15:13:39 <acozine> I used writer's tools instead of developer's tools - cloned, opened in an editor, and did a global search (which no doubt uses grep under the covers)
15:13:39 <samccann> grep: Trailing backslash
15:14:00 <samccann> oh wait, didn't grab the whole thing.... trying again
15:14:13 <acozine> gundalow where's that list of collections included in the ansible package?
15:15:15 <samccann> ok grep -ER 'M\([^.)]+\)' . requires a space before the M but otherwise, assuming community.general is all fixed, it came back clean
15:16:00 <felixfontein> gundalow: I think andersson007 had a script for seealso
15:16:12 <samccann> is this the correct grep for seealso - grep -ER ' seealso\([^.)]+\)' .
15:16:48 <felixfontein> samccann: on, seealso doesn't have brackets
15:17:06 <felixfontein> grepping for `seealso:` should be good, but there's no automated way to check whether the entries in there are FQCN or not
15:20:17 <samccann> is there a way to have grep spit out the line where it finds the seealso?
15:21:02 <samccann> acozine: just saw your bit about using the editor... will try that
15:25:16 <felixfontein> 17:24 < felixfontein> maybe it makes sense to reorganize the ACD changelog to collect all new modules/plugins of all included collections in one place, instead of listing the in the section for every collection
15:25:25 <felixfontein> acozine: samccann: ^ thoughts on this?
15:25:43 <felixfontein> (in #ansible-community we were talking about discoverability of new modules/plugins in 2.10)
15:25:54 <acozine> ah
15:26:05 * acozine needs to join more channels from this IRC client
15:26:15 <felixfontein> I thougth you're probably not there because of irccloud :)
15:26:24 <acozine> you are correct
15:26:30 <samccann> sadly the editor trick doesn't work for me. So I can't determine if seealso has been fixed or not
15:26:47 <acozine> samccann atom has a nifty "find in project" option
15:26:59 <acozine> felixfontein I think calling out all new modules/plugins is a good idea
15:27:23 <acozine> I mean, putting them in a group, using FQCN, instead of putting each one in its collection
15:27:25 <felixfontein> acozine: they are already called out, but inside the changelog part for every colletion - so you'd have to scroll through everything to see new modules/plugins
15:27:27 <acozine> in the changelog
15:27:32 <felixfontein> yep
15:27:36 <samccann> that's what I used acozine. It finds them, but then I have to click on every single one to open up that page and see if it's FQCN or not
15:27:48 <acozine> samccann oh, it doesn't show you the line?
15:28:04 <felixfontein> acozine: `seealso` is a YAML list, so the interesting lines are the lines after it
15:28:09 <gundalow> acozine: collections included in `ansible-2.10` package: https://github.com/ansible-community/ansible-build-data/blob/main/2.10/acd.in
15:28:20 <acozine> when I did it for M( it showed enough of the line that I could see the collection name
15:28:25 <acozine> samccann ah, yeah
15:28:42 <acozine> I wonder if that's configuration samccann
15:28:53 <acozine> gundalow thanks
15:29:28 <felixfontein> acozine: M(...) is all in one line. seealso is not :)
15:29:39 <samccann> ^ that
15:29:42 <acozine> yeah
15:29:48 <acozine> I don't know how to get around that
15:30:01 <acozine> and a lot of the seealso entries point to other resources
15:30:05 <acozine> not to modules/plugins
15:30:05 <felixfontein> grep has a option to always show you the next N lines (or the prev M lines)
15:30:14 <felixfontein> I think `grep -A 5 ...` shows the next 5 lines after every match
15:30:17 <samccann> oh that would help!
15:30:20 <samccann> trying that
15:31:02 <felixfontein> of course there might be a lot more seealso entries then you can see right away, so it's only partially helpful in this specific case
15:31:05 <samccann> meanwhile on all new modules - we'd have the same discoverability problem for deprecated and removed modules, wouldn't we?
15:32:02 <felixfontein> samccann: that's true, but we don't have that in a processable way, since deprecation and removal parts are free-form text. but they are better organized in the porting guide
15:33:54 <samccann> anyway I'm fine with grouping them at the top. makes sense
15:34:01 <samccann> with FQCN :-)
15:34:21 <acozine> I've added a section to the bottom of etherpad to track which collections we know are fixed: https://etherpad.opendev.org/p/virtual-ansible-contributor-summit-july-2020
15:34:49 <acozine> I put notes on community.aws and community.crypto, then made the style strikethrough
15:34:58 <samccann> sadly this isn't giving me extra lines either - grep -A 5 -rl  seealso ./
15:38:09 <samccann> acozine how are you finding the seealso references?
15:38:24 <acozine> I got lucky
15:38:30 <acozine> the collection I was looking at didn't have any
15:40:59 <samccann> ok imma take felixfontein word on it that community.general is already fixed for seealso
15:41:48 <acozine> I thought he was talking about community.crypto?
15:42:21 <samccann> I thought he said c.g and c.n were good to go
15:42:32 <samccann> c.n has no seealso but c.g has a crapton
15:42:59 <samccann> question - does seealso work if the module is in the same collection?
15:43:07 <samccann> (w/o FQCN)
15:43:12 <acozine> ooh, you can configure atom to show more lines on findinproject
15:43:22 <samccann> ooooo clever clever you!
15:43:26 <samccann> see question above
15:43:55 <acozine> I think all seealso links, even within the same collection, need to use FQCN
15:44:18 <acozine> we discussed that, and decided that esp. for community.general, that approach would be short-term pain but long-term gain
15:44:27 <acozine> because we expect modules to move out of community.general
15:45:37 <acozine> I can't be 100% sure, but the seelaso entries in community.general are at least mostly FQCNs
15:45:56 <acozine> atom shows a max of 3 additional lines
15:49:39 <acozine> about two-thirds of the seealso  refs in community.general point either to a tightly related module (for example, postgresql_privs points to postgresql_user) or to outside references
15:50:06 <acozine> but some of them point to unrelated or semi-related modules in community.general
15:50:25 <acozine> so we are going to need a linkchecking routine as new collections get spun off from community.general
15:54:31 * acozine is going down the list in the etherpad, checking community.digitalocean now
15:55:34 <acozine> that one's fine
15:55:40 <acozine> doing community.grafana next
15:55:43 <felixfontein> samccann: seealso always needs the FQCN
15:57:58 <acozine> community.grafana and community.kubernetes are both clean
15:58:13 <acozine> they have no M() entries and no seealso sections
15:58:18 <acozine> on to libvirt
16:01:42 <samccann> ah then community.general isn't fixed for seealso
16:01:52 <samccann> I found at least one so far that had just the module names, not fqcn
16:05:19 <acozine> in community.general?
16:07:31 <acozine> the M() references in the community.azure collection need updating
16:08:41 * abadger1999 doesn't have scrollback to read what came before this but... M() references need to be updated all over the place :-)   (including ansible-base)
16:11:55 <abadger1999> Almost 1000: https://gist.github.com/abadger/158d752815845cf3e63bbc738ca203f4  I think that almost all of the warnings there that are for undefined label need to be updated to a FWCN.
16:11:58 <abadger1999> *FQCN
16:13:09 <samccann> sorry multitaksing WAAAAY oo much this am and just not getting a grip
16:13:17 <samccann> acozine - yes in community.general
16:13:54 <acozine> ah, my mistake then
16:16:04 <samccann> omgosh just shoot me now
16:16:08 <samccann> SHOOT ME NOW!
16:16:30 <samccann> so I found it with the atom editor, but I can't find it when I go to github. it's fqcn in github
16:16:40 <acozine> that's weird
16:16:55 <samccann> i did a fresh pull but obviously didn't do it right
16:16:58 <acozine> for community.azure I opened https://github.com/ansible-collections/community.azure/issues/4
16:17:07 <acozine> so it is fixed after all?
16:18:51 <samccann> anyway yes, two hrs later... community.general is fixed for both M and seealso
16:19:25 <samccann> find in project doesn't actually ...find...in...project. If finds in ALL projects and was somehow picking up an old version of community.general
16:19:44 <samccann> I deleted all my other projects (in atom editor) and now I can see it's hunky dory
16:20:16 <acozine> heh, meanwhile I just tried to use autocomplete for the collection name I wanted to git clone . . .
16:20:24 <acozine> computer, read my mind!
16:21:03 <samccann> lol
16:22:07 <acozine> ah, abadger1999's error output finds all these non-FQCNs for us
16:22:36 <acozine> no need to grep
16:22:40 <acozine> or open stuff in atom
16:22:50 <samccann> ??
16:23:06 * acozine hums that line from Hamilton . . . "Technology! We get the job done."
16:23:13 <samccann> AAAHAHAHAH
16:23:44 <acozine> samccann see the gist he posted 12 minutes ago
16:24:18 <samccann> bless you abadger1999 !!!
16:24:25 <acozine> not all the errors relate to missing FQCNs
16:24:34 <acozine> but all the ones that do relate to missing FQCNs are there
16:25:23 <samccann> ok so the next question.  Should we just open up issues in the collection and dump the error output there?
16:25:37 <acozine> I think that's a fine idea
16:25:40 <samccann> as in 'please fix these problems for getting docs into ansible
16:25:47 <acozine> yep
16:26:51 <samccann> ok I feel like before I start opening the issue, I'll want to check what the warnings mean (all those undefined labels etc)
16:27:23 <samccann> mostly because I quite frankly, haven't done a SINGLE THING correctly the first time this morning
16:27:40 <samccann> but mostly mostly... I need food
16:27:41 <abadger1999> Cool :-)
16:28:42 <samccann> oh.. .are the pipeline docs up on a test site? All these line numbers refer to .rst lines so collection owners won't know where to find the error
16:30:22 <samccann> like what does this mean? /srv/ansible/stable-2.10/docs/docsite/rst/collections/amazon/aws/aws_s3_module.rst:608: WARNING: undefined label: ansible_collections.aws_s3_module (if the link has no caption the label must precede a section header)
16:30:50 <samccann> does it mean it needs to be ansible_collections.aws.aws_s3 instead?
16:31:07 <samccann> does it mean someone tried to use the short name and short name doesn't work?
16:38:54 <abadger1999> Hmmm....  I can upload the generated rst.
16:41:53 <abadger1999> samccann: Yeah, the warning is coming from the generated rst...  The chain of the error is: there's something like `M(aws_s3)` in the aws_s3.py module.  The docs pipeline turns that into `:ref:ansible_collections.aws_s3_module` in the `rst/collections/amazon/aws/aws_s3_module.rst` file.  Then sphinx-build is run on that file and generates that
16:41:53 <abadger1999> error
16:42:27 <abadger1999> The solution is to change `M(aws_s3)` to `M(amazon.aws.aws_s3)` in the aws_s3.py module.
16:42:51 * abadger1999 making a place to upload the generated rst now.
16:44:04 <acozine> abadger1999 the error output helps a lot - if nothing else, it tells us which collections have issues and which ones (by process of elimination) don't
16:49:41 * acozine is headed to lunch
16:52:11 <abadger1999> samccann acozine: Okay, uploaded.... As an example, the generated rst for the aws_s3 module is here: https://toshio.fedorapeople.org/ansible/docsite-rst/collections/amazon/aws/aws_s3_module.rst    and the html that's generated from that is here: https://toshio.fedorapeople.org/ansible/docsite/collections/amazon/aws/aws_s3_module.html
16:53:48 <abadger1999> Looks like the warning for the aws_s3 module is coming from this line in the rst:    - In 2.4, this module has been renamed from ``s3`` into :ref:`aws_s3 <ansible_collections.aws_s3_module>`.
16:54:08 <abadger1999> Which the collection owner would then trace to this line in the module: https://github.com/ansible-collections/amazon.aws/blob/main/plugins/modules/aws_s3.py#L19
16:54:38 <baptistemm> hello again
16:55:13 <acozine> abadger1999 thanks, that one looks like we could just remove it - 2.4 is a long time ago
16:55:20 <acozine> baptistemm welcome back
16:55:39 <acozine> if you're looking for an issue to work on, have a look at https://github.com/ansible-collections/community.azure/issues/4
16:55:48 <acozine> meanwhile, I'm really, really going to grab some lunch now
16:56:01 <abadger1999> :-)
16:57:11 <baptistemm> so I'm a bit lost, who is doing what, how can I help.
16:58:28 <baptistemm> abadger1999: are you doing all builtin modules ?
17:00:54 <baptistemm> ah no
17:08:18 <abadger1999> Nope... I think if you wanted to do all builtin modules, no one else is.
17:08:30 <abadger1999> baptistemm Just say what you are working on here.
17:09:37 <baptistemm> I took podman, so did 'grep -ER 'M\([^.)]+\)' .' to find M() but  found nothing
17:09:53 <abadger1999> baptistemmOkay.  It could also be a seealso line.
17:09:58 <abadger1999> Let me take a look
17:11:45 <baptistemm> grep -Ri seealso . returned nothing
17:11:55 <abadger1999> baptistemm Hmm..... podman isn't in my list: https://gist.github.com/abadger/158d752815845cf3e63bbc738ca203f4
17:12:43 <abadger1999> baptistemm So I think you aren't finding those because there's no problems in those modules.
17:14:41 <baptistemm> ah I take the one on etherpad
17:25:12 <samccann> welcome back baptistemm
17:25:27 <samccann> I've waffled most of the morning away doing things the wrong way for sure
17:26:19 <samccann> I think the approach now is to use abadger1999 gist to find collections with problems, then open an issue against the collection to get them fixed
17:26:25 <baptistemm> abadger1999: taking Juniper
17:26:40 <samccann> that gist has all the problems building against the docs pipeline
17:26:57 <baptistemm> will take me some time it's dinner time for the kids
17:27:06 <samccann> if you are inclined to jump in and create a PR, that's cool too
17:27:16 <samccann> :-)
17:27:38 * samccann waves to the little baptistems
17:28:07 <samccann> I'm going to grab amazon and see if I can just fix directly in a PR as it seems to be a short list
17:44:13 <samccann> https://github.com/ansible-collections/amazon.aws/pull/97
17:44:24 <samccann> grabbing ansible.netcommon next
17:52:15 <baptistemm> what about the C() reference ?
17:52:26 <samccann> I think they all still work
17:52:45 <samccann> check the gist abadger1999 put up above
17:53:31 <samccann> speaking of which - abadger1999 - the fQCN for modules still in ansible-base are ansible.builtin.modulename right?
17:53:32 <felixfontein> baptistemm: C(...) is not a reference
17:53:49 <felixfontein> samccann: yes
17:53:53 <samccann> thanks!
17:54:01 <baptistemm> samccann: I was about to ask the same
17:54:10 <baptistemm> thanks
17:54:57 <felixfontein> ansible.builtin is the name of the synthetic collection of modules/plugins contained in ansible/ansible
17:55:18 <felixfontein> though I *think* the core team does not want to show this name to users, if possible
17:56:06 <baptistemm> indeed
17:56:08 <felixfontein> (I spent some time implementing a change for ansible-doc which would show that for built-in modules and plugins, and found out that this wasn't wanted)
17:56:35 <baptistemm> I got that "with an initial C(M(!)) to specify"
17:56:40 <felixfontein> which makes it a bit awkward that the docs for the builtin modules and plugins might display this collection name
17:56:59 <felixfontein> baptistemm: I found that several times in community.network, I think it was copy'n'pasted from one source
17:57:10 <felixfontein> baptistemm: I simply removed the M() part, i.e. reduced it to `C(!)`.
17:58:24 <felixfontein> DING DING DING community meeting in #ansible-community IN TWO MINUTES!
17:58:44 <samccann> felixfontein abadger1999 - afaik the only way to remove the docs pipeline warning for M() against an ansible-base module is to use ansible.builtin.
17:59:05 <felixfontein> samccann: that's what I mean with awkward :)
17:59:08 <samccann> heh
17:59:22 <felixfontein> I wonder what the core team thinks about this
17:59:50 <samccann> gooood question!
18:00:50 <gundalow> FYI Community meeting in #ansible-community
18:00:57 <gundalow> just started
18:03:56 <samccann> k. gonna switch over there
18:10:57 <felixfontein> what's the current state for the docsite for 2.10 and/or later, i.e. the split between ansible and ansible-base?
18:11:07 <felixfontein> I wasn't really around today and yesterday, so in case this was discussed, I missed it...
18:15:02 <samccann> nothing being split out yet. Doubt much will happen in that regard before 2.10
18:15:32 <samccann> so 2.10 docs will be much the same as it is today, but with the collection module docs added back
18:15:33 <felixfontein> the fun will begin when ansible-base and ansible will start having divergent version numbers
18:15:45 * samccann craws back under rock
18:15:49 <felixfontein> :)
18:17:03 <samccann> is there any current plan for that happening? As in when's the next ansible release?
18:17:17 <felixfontein> that's a very good question :)
18:17:24 <felixfontein> I have no idea what the current plan is for ansible-base
18:17:56 <felixfontein> there have been rumors about an early 2.11 version (in october even?), but that might have been buried again since a long time... it has been months ago when I heard about it
18:18:04 <samccann> I'm guessing it just keeps on keepin on (around the 6 month cycle).  The question becomes, will ansible (aka acd) release before that
18:18:21 <samccann> oh haha you're more in the know than I am for sure
18:19:03 <felixfontein> I'm pretty sure that I'm not, or at least that now I know nothing more than you do :)
18:32:59 <samccann> should we close out this dockathon since most of us are over in the community meeting at this point?
18:33:34 <samccann> acozine: ^^ ?
18:42:21 <baptistemm> naming of junos modules is meh junipernetworks.junos.junos_logging why don't they drop junos from module name
18:42:50 <baptistemm> junipernetworks.junos.logging would have been better
18:44:20 <baptistemm> When I create a PRs for M() link should I reference another issue so it can be easily tracked ?
18:47:20 <samccann> for junipernetworks - the modules were already called junos_logging before the whole collection world came about
18:47:42 <baptistemm> samccann: moving to collection does not allow renaming them ?
18:47:48 <samccann> there was 'some mumbling' about allowing short FQCN names to help with that, but I don't recall where that ended up
18:47:49 <acozine> baptistemm: if there's an issue open in the collection, reference that
18:48:02 <samccann> not if you want things backward compatible, which the network team did want
18:48:10 <baptistemm> samccann: I'll open an issue to ask
18:48:36 <acozine> yes, moving to collections does allow renaming
18:48:43 <acozine> but it might break old playbooks
18:49:00 <acozine> unless it's possible to add aliases for modules in collections
18:49:34 <acozine> samccann: yes, I think we can close this meeting
18:49:56 <baptistemm> acozine: I don't see any link :)
18:50:29 <acozine> baptistemm the only issue I created was https://github.com/ansible-collections/community.azure/issues/4
18:50:36 <felixfontein> baptistemm: samccann: I think some collections renamed their modules accordingly, but others didn't
18:50:58 <acozine> but having a central issue might be a good idea
18:51:09 <felixfontein> the problem is that if someone uses `collection:`, this can quickly get confusing since generic shortnames could show up in multiple collections, and lead to conflicts
18:51:09 <acozine> for all collections updates related to M() and seealso
18:51:15 <acozine> I'm just not sure what repo to put that in
18:52:00 <acozine> it does not belong in ansible/ansible; is there a repo under the ansible-collections namespace for "stuff related to all collections"?
18:53:20 <baptistemm> https://github.com/ansible-collections/junipernetworks.junos/pull/79
18:53:32 <felixfontein> ansible-collections/overview :)
18:53:38 <acozine> ah, yes
18:53:39 <acozine> https://github.com/ansible-collections/overview/issues
18:53:47 <felixfontein> I think that's currently the best place
18:53:51 <acozine> okay baptistemm thanks for the PR!
18:53:58 <baptistemm> argh too many repos
18:54:24 <acozine> When the current meeting(s) are over I will open an issue there and link to your PR and to the issue in  community.azure
18:54:35 <acozine> baptistemm exactly!
18:55:12 <baptistemm> and junos use plural for module which is discouraged
18:56:17 <acozine> heh, yep
18:56:51 <samccann> acozine: there may already be an issue that mentions FQCN updates in that repo
18:57:20 <acozine> that would be *awesome*
18:58:00 <samccann> i'll check once the community meeting is over
18:58:02 <samccann> too
18:58:03 <samccann> much
18:58:06 <samccann> multitasking
18:58:34 <acozine> samccann there's https://github.com/ansible-collections/overview/issues/50
18:59:12 <acozine> and https://github.com/ansible-collections/overview/issues/40
18:59:22 <acozine> but neither one mentions the M() or seealso stuff
19:01:03 <baptistemm> https://stackoverflow.com/questions/62800279/failure-in-adding-new-module-in-existing-ansible-plugin people starting to develop collection
19:01:13 <baptistemm> "The documentation updates are not exactly exhaustive though, that's my opinion."
19:03:57 <acozine> sigh
19:04:18 <baptistemm> at least there is feedback
19:04:47 <acozine> true, and maybe this AJ could join the docs community!
19:04:58 <acozine> and s/he is not wrong
19:05:14 <baptistemm> I can put an answer :)
19:05:27 <acozine> baptistemm thanks!
19:05:28 <samccann> https://github.com/ansible-collections/overview/issues/45#issuecomment-648405709
19:05:52 <samccann> for the issue that covers seealso.  there's a big ol issue for 'everything a collection owner needs to do'
19:09:48 <acozine> samccann ah, that's great
19:10:26 <acozine> I think I will still create a standalone issue so we can post the "Hall of Shame" list from abadger1999's error output, and so we can track which ones get fixed
19:11:52 <acozine> I'll link to issue 45 and specifically to your comment there
19:15:52 <samccann> kewl
19:18:28 <acozine> https://github.com/ansible-collections/overview/issues/89
19:23:02 <samccann> kewl
19:26:51 <baptistemm> I link all PRs to there
19:27:39 <samccann> thanks baptistemm !!
19:27:40 <acozine> baptistemm excellent, thanks!
19:31:54 <baptistemm> taking vyos
19:32:08 * acozine cheers
19:35:27 <samccann> so i found that the gist doesn't have all the M() items listed. So the grep might still come in handy
19:35:50 <samccann> jill r mentioned one I missed in the PR and it's not in the gist
19:39:05 <abadger1999> samccann <nod> Could you point me at which module it is?  I would be interested in taking a look.
19:40:38 <acozine> abadger1999: https://github.com/ansible-collections/amazon.aws/pull/97#pullrequestreview-445036665
19:43:05 <abadger1999> Thanks
19:43:26 <samccann> thanks acozine
19:43:49 <acozine> np, i was just closing that tab
19:44:07 * acozine is down to maybe a dozen tabs . . . amazing!
19:48:11 <abadger1999> samccann, acozine: Oh, I see why that isn't getting reported.  It's in the html table output so on the website it doesn't get turned into a link
19:48:43 <acozine> ah, interesting
19:48:45 <abadger1999> So sphinx is just rendering what the html table includes verbatim.
19:49:18 <abadger1999> This is a snippet from the rst file: `functionality has been moved to a dedicated module <span class='module'>ec2_tag_info</span>.`
19:50:02 <abadger1999> So yeah, anyplace in the plugin options won't generate a sphinx warning and we might still have to grep for those.
19:50:23 <felixfontein> so essentially build the HTML version, and run a dead link finder on it?
19:50:37 <samccann> that... is a scary world felixfontein
19:50:39 <samccann> :-)
19:52:39 <felixfontein> samccann: indeed :)
19:52:53 <abadger1999> felixfontein: That won't work either because it's not a link.
19:53:01 <abadger1999> It just gets <span> formatting.
19:53:11 <felixfontein> abadger1999: in this case, definitely true
19:55:06 <abadger1999> If someone implements this: https://github.com/ansible-community/antsibull/issues/45  then we could run the linkchecker.
19:58:30 <abadger1999> acozine: I think the stable-2.10 PR should build docs now.
19:58:54 <abadger1999> I'm working on getting the two PRs to pass tests now.
19:59:33 <abadger1999> But before I finish that, I have to take a nap.
20:01:07 <felixfontein> abadger1999: I guess it would also be possible to implement a link checker (at least for links into collections for which docs are built in the same run), since we already know which modules/plugins exist in which collection?
20:01:23 <felixfontein> (but definitely something for later, not for now ;) )
20:01:39 <abadger1999> <nod>
20:03:21 <baptistemm> taking nxos
20:03:54 <samccann> thanks baptistemm !!
20:04:25 <samccann> meanwhile sphinx has a linkchecker... check ansible/ansible for it in the make file and conf.py.  Dunno if that will help with the docs pipeline tho
20:05:40 <felixfontein> it never hurts to have an additional checker
20:12:37 <baptistemm> nxos done
20:29:37 <baptistemm> taking command from builtin
20:30:44 <baptistemm> and shell
20:42:47 <baptistemm> did copy
20:47:57 <baptistemm> let's call it a day
20:54:53 <samccann> thanks baptistemm !!
20:55:03 <samccann> #endmeeting