13:43:20 #startmeeting Hackathon Day Two 13:43:20 Meeting started Wed Jul 8 13:43:20 2020 UTC. 13:43:20 This meeting is logged and archived in a public location. 13:43:20 The chair is acozine. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:43:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:43:20 The meeting name has been set to 'hackathon_day_two' 13:43:51 welcome to the second day of the Ansible Community Hackathon 13:44:04 we'll spend at least part of today on docs issues 13:44:04 woot woot 13:44:32 who is around? 13:44:37 * gundalow waves 13:44:47 #chair baptistemm gundalow samccann 13:44:47 Current chairs: acozine baptistemm gundalow samccann 13:45:19 we have a bunch of tidying to do on module docs in collections 13:45:35 Excellent 13:47:22 * acozine digs around for links 13:48:47 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 we still have these 13:49:23 felixfontein hi! 13:49:28 #chair felixfontein 13:49:28 Current chairs: acozine baptistemm felixfontein gundalow samccann 13:49:43 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 baptistemm: I have no backlog at all today 13:53:10 but we did post a log from yesterday . . . 13:53:12 um . . . 13:53:27 Docs hackathon actions: https://meetbot.fedoraproject.org/ansible-docs/2020-07-07/ansible_docs_hackathon.2020-07-07-14.05.html 13:53:27 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 (thanks gundalow!) 13:54:17 here's the PR that enabled M(...) and `seealso` in module docs for the new pipeline 13:54:19 https://github.com/ansible-community/antsibull/pull/92 13:55:02 M() is for Module ? 13:55:58 baptistemm yes, the `M()` syntax makes a link to another module within the text of the DOCUMENTATION 13:56:32 the `seealso` syntax creates a box with one or more links to other modules 13:56:40 at the bottom of the DOCUMENTATION section 13:57:47 in the new collections ecosystem, those links need to provide the FQCN for the module they link to 13:59:55 here's a gist showing those modules from 2.9: 13:59:57 https://gist.github.com/acozine/052a6f966f377b662b8e8eaaa70e2c3e 14:01:07 so we could create issues in the relevant collections, or just open PRs to update those links to use FQCN 14:01:16 (or both, of course) 14:02:09 I'll do a list of M() instances in a minute 14:02:48 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 (as in would that grep work just as well per collection?) 14:03:24 yes, it would catch any new `seealso` sections that have been added 14:03:55 that list from 2.9 is a good starting point 14:04:01 but there might be more 14:04:21 * acozine has a small home distraction, AFK 5 14:05:11 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 Issue per repo with a list of things to fix would be good 14:05:24 some of that I think fixed the M() for sure 14:05:50 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 I also need to drop for other meetings, I'll keep an eye on IRC 14:06:06 the link is in the etherpad already 14:06:20 if you have some example commit, I can help doing PRs 14:06:29 for the script. I can ask them for what all it fixes besides a few docs things 14:06:45 #actoin samccann to delve into what network team script fixes 14:06:52 omgosh cannot spell today! 14:07:08 #action samccann to delv into what network team script fixes 14:07:24 hmm. dunno if that's working or not 14:07:42 anyway baptistemm : thanks! that will help for sure 14:09:01 * samccann digs up link to script 14:09:56 #link https://github.com/ansible-network/collection_prep 14:10:31 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 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 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 #info need someone to generalize those scripts to make them available to all collection owners for general pre-release cleanup steps 14:15:24 I added a second file to the gist, showing which modules in 2.9 used the `M()` syntax 14:15:46 https://gist.github.com/acozine/052a6f966f377b662b8e8eaaa70e2c3e 14:16:05 #link https://gist.github.com/acozine/052a6f966f377b662b8e8eaaa70e2c3e 14:16:22 #info includes M() and :seealso: from 2.9 for reference. 14:17:05 again, other modules in more collections may have that now, but the ones in that gist form a good starting point 14:17:25 #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 is there anything we can do right now toward that goal? 14:18:12 to add the 'hack' to hackathon :-) 14:19:38 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 or open an issue with a list of modules that need fixing, post the issue here 14:21:21 perhaps people should tell which one they working on ? 14:21:27 to avoid collision 14:21:32 ok I'm going to grab community.network 14:21:41 baptistemm yes, good idea 14:21:55 etherpad is good also 14:22:00 whateer fits 14:22:01 baptistemm thanks for catching that typo on PR 70488! 14:22:07 I cannot work now but plan later in the day 14:22:33 baptistemm awesome, thanks! 14:22:42 acozine: did my duty at 4:00 AM 14:23:20 ah, well, thanks for putting your insomnia to good use 14:23:25 hope you get better sleep tonight! 14:23:37 blame mosquitos 14:23:55 arrived for 3 days and I'm up at 4:00 AM since then 14:24:07 ugh, that sounds awful 14:24:15 s/blame/thanks/ 14:24:21 heh 14:24:58 not that awful, but instead of hitting myself to squizz them I go downstairs and read the internet 14:28:35 that's very productive of you baptistemm 14:32:18 * baptistemm would like to make its ansible code by now ... 14:32:25 +works 14:40:06 sorry in another meeting so multitasking but this is the first issue - https://github.com/ansible-collections/community.network/issues/86 14:40:14 let me know if I should have more detail there or not 14:49:12 ok going to move onto community.general now 14:50:52 woot! Thanks samccann 14:58:06 I'll do community.crypto 15:02:09 what are you planning to do in community.crypto? 15:02:12 acozine: 15:02:34 felixfontein create an issue for which modules have seealso and M() references 15:02:36 FQCNs in references are already there (thanks to abadger) 15:02:44 ohhh, okay 15:02:45 he updated both M(...) and seealso some time ago 15:02:48 heh 15:02:56 just created the issue for community.general - https://github.com/ansible-collections/community.general/issues/632 15:02:56 feel free to look again, but I think all have been fixed :) 15:02:58 so I need to be more sophisticated in how I search 15:03:09 i feel like maybe I should move the full list down to a comment? seems... long 15:03:28 I can check community.crypto next if you want 15:03:31 I think M(...) and seealso have already been fixed in c.g and c.n as well 15:03:49 hmm. maybe I'm doing something wrong then. the list was huge 15:04:04 but maybe the grep assumes all M(..) have not been fixed and we're doing this wrong 15:04:05 it's still called M(...) :) 15:04:18 the grep simply finds all `M(` 15:04:20 sigh. At least I started w. your two collections... 15:04:41 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 yeah, sorry, I forgot that some had already been fixed 15:04:54 andersson007 fixed all the seealsos, and I think I fixed the M(...)s manually 15:05:07 the only things that aren't fixed in c.g and c.n are FQCNs in examples 15:05:31 Those scripts I pointed to in the issue fix that as well. just not sure which one or which part 15:05:34 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 (fixes FQCN) 15:06:02 that would be useful 15:06:13 so is there a clever grep that would check for M( that does NOT start with community.general? 15:07:22 hrm, even that wouldn't work 15:07:40 because M( can refer to modules in another collection 15:07:41 I guess there is, but you'd need advanced regex. Essentially grep for `M\([^.)]+\)` 15:07:52 yeah, that would work 15:08:01 with the correct options; maybe `grep -ER 'M\([^.)]+\)' .` will do the trick 15:08:05 "find me anything that starts with M( and doesn't have a period in it" 15:08:16 no period == no collection name 15:08:24 exactly 15:08:55 I can read regex, sort of, i just can't write it without a "dictionary" at hand 15:10:02 ok I'll try that thanks 15:10:20 felixfontein: did andersson007 have a script to fix these? 15:12:26 I just checked community.aws, the M( refs have already been fixed there 15:12:43 no seealso in the modules there 15:13:39 hmm... grep -ER 'M\([^.)]+\' 15:13:39 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 grep: Trailing backslash 15:14:00 oh wait, didn't grab the whole thing.... trying again 15:14:13 gundalow where's that list of collections included in the ansible package? 15:15:15 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 gundalow: I think andersson007 had a script for seealso 15:16:12 is this the correct grep for seealso - grep -ER ' seealso\([^.)]+\)' . 15:16:48 samccann: on, seealso doesn't have brackets 15:17:06 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 is there a way to have grep spit out the line where it finds the seealso? 15:21:02 acozine: just saw your bit about using the editor... will try that 15:25:16 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 acozine: samccann: ^ thoughts on this? 15:25:43 (in #ansible-community we were talking about discoverability of new modules/plugins in 2.10) 15:25:54 ah 15:26:05 * acozine needs to join more channels from this IRC client 15:26:15 I thougth you're probably not there because of irccloud :) 15:26:24 you are correct 15:26:30 sadly the editor trick doesn't work for me. So I can't determine if seealso has been fixed or not 15:26:47 samccann atom has a nifty "find in project" option 15:26:59 felixfontein I think calling out all new modules/plugins is a good idea 15:27:23 I mean, putting them in a group, using FQCN, instead of putting each one in its collection 15:27:25 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 in the changelog 15:27:32 yep 15:27:36 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 samccann oh, it doesn't show you the line? 15:28:04 acozine: `seealso` is a YAML list, so the interesting lines are the lines after it 15:28:09 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 when I did it for M( it showed enough of the line that I could see the collection name 15:28:25 samccann ah, yeah 15:28:42 I wonder if that's configuration samccann 15:28:53 gundalow thanks 15:29:28 acozine: M(...) is all in one line. seealso is not :) 15:29:39 ^ that 15:29:42 yeah 15:29:48 I don't know how to get around that 15:30:01 and a lot of the seealso entries point to other resources 15:30:05 not to modules/plugins 15:30:05 grep has a option to always show you the next N lines (or the prev M lines) 15:30:14 I think `grep -A 5 ...` shows the next 5 lines after every match 15:30:17 oh that would help! 15:30:20 trying that 15:31:02 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 meanwhile on all new modules - we'd have the same discoverability problem for deprecated and removed modules, wouldn't we? 15:32:02 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 anyway I'm fine with grouping them at the top. makes sense 15:34:01 with FQCN :-) 15:34:21 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 I put notes on community.aws and community.crypto, then made the style strikethrough 15:34:58 sadly this isn't giving me extra lines either - grep -A 5 -rl seealso ./ 15:38:09 acozine how are you finding the seealso references? 15:38:24 I got lucky 15:38:30 the collection I was looking at didn't have any 15:40:59 ok imma take felixfontein word on it that community.general is already fixed for seealso 15:41:48 I thought he was talking about community.crypto? 15:42:21 I thought he said c.g and c.n were good to go 15:42:32 c.n has no seealso but c.g has a crapton 15:42:59 question - does seealso work if the module is in the same collection? 15:43:07 (w/o FQCN) 15:43:12 ooh, you can configure atom to show more lines on findinproject 15:43:22 ooooo clever clever you! 15:43:26 see question above 15:43:55 I think all seealso links, even within the same collection, need to use FQCN 15:44:18 we discussed that, and decided that esp. for community.general, that approach would be short-term pain but long-term gain 15:44:27 because we expect modules to move out of community.general 15:45:37 I can't be 100% sure, but the seelaso entries in community.general are at least mostly FQCNs 15:45:56 atom shows a max of 3 additional lines 15:49:39 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 but some of them point to unrelated or semi-related modules in community.general 15:50:25 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 that one's fine 15:55:40 doing community.grafana next 15:55:43 samccann: seealso always needs the FQCN 15:57:58 community.grafana and community.kubernetes are both clean 15:58:13 they have no M() entries and no seealso sections 15:58:18 on to libvirt 16:01:42 ah then community.general isn't fixed for seealso 16:01:52 I found at least one so far that had just the module names, not fqcn 16:05:19 in community.general? 16:07:31 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 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 *FQCN 16:13:09 sorry multitaksing WAAAAY oo much this am and just not getting a grip 16:13:17 acozine - yes in community.general 16:13:54 ah, my mistake then 16:16:04 omgosh just shoot me now 16:16:08 SHOOT ME NOW! 16:16:30 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 that's weird 16:16:55 i did a fresh pull but obviously didn't do it right 16:16:58 for community.azure I opened https://github.com/ansible-collections/community.azure/issues/4 16:17:07 so it is fixed after all? 16:18:51 anyway yes, two hrs later... community.general is fixed for both M and seealso 16:19:25 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 I deleted all my other projects (in atom editor) and now I can see it's hunky dory 16:20:16 heh, meanwhile I just tried to use autocomplete for the collection name I wanted to git clone . . . 16:20:24 computer, read my mind! 16:21:03 lol 16:22:07 ah, abadger1999's error output finds all these non-FQCNs for us 16:22:36 no need to grep 16:22:40 or open stuff in atom 16:22:50 ?? 16:23:06 * acozine hums that line from Hamilton . . . "Technology! We get the job done." 16:23:13 AAAHAHAHAH 16:23:44 samccann see the gist he posted 12 minutes ago 16:24:18 bless you abadger1999 !!! 16:24:25 not all the errors relate to missing FQCNs 16:24:34 but all the ones that do relate to missing FQCNs are there 16:25:23 ok so the next question. Should we just open up issues in the collection and dump the error output there? 16:25:37 I think that's a fine idea 16:25:40 as in 'please fix these problems for getting docs into ansible 16:25:47 yep 16:26:51 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 mostly because I quite frankly, haven't done a SINGLE THING correctly the first time this morning 16:27:40 but mostly mostly... I need food 16:27:41 Cool :-) 16:28:42 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 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 does it mean it needs to be ansible_collections.aws.aws_s3 instead? 16:31:07 does it mean someone tried to use the short name and short name doesn't work? 16:38:54 Hmmm.... I can upload the generated rst. 16:41:53 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 error 16:42:27 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 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 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 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 `. 16:54:08 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 hello again 16:55:13 abadger1999 thanks, that one looks like we could just remove it - 2.4 is a long time ago 16:55:20 baptistemm welcome back 16:55:39 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 meanwhile, I'm really, really going to grab some lunch now 16:56:01 :-) 16:57:11 so I'm a bit lost, who is doing what, how can I help. 16:58:28 abadger1999: are you doing all builtin modules ? 17:00:54 ah no 17:08:18 Nope... I think if you wanted to do all builtin modules, no one else is. 17:08:30 baptistemm Just say what you are working on here. 17:09:37 I took podman, so did 'grep -ER 'M\([^.)]+\)' .' to find M() but found nothing 17:09:53 baptistemmOkay. It could also be a seealso line. 17:09:58 Let me take a look 17:11:45 grep -Ri seealso . returned nothing 17:11:55 baptistemm Hmm..... podman isn't in my list: https://gist.github.com/abadger/158d752815845cf3e63bbc738ca203f4 17:12:43 baptistemm So I think you aren't finding those because there's no problems in those modules. 17:14:41 ah I take the one on etherpad 17:25:12 welcome back baptistemm 17:25:27 I've waffled most of the morning away doing things the wrong way for sure 17:26:19 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 abadger1999: taking Juniper 17:26:40 that gist has all the problems building against the docs pipeline 17:26:57 will take me some time it's dinner time for the kids 17:27:06 if you are inclined to jump in and create a PR, that's cool too 17:27:16 :-) 17:27:38 * samccann waves to the little baptistems 17:28:07 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 https://github.com/ansible-collections/amazon.aws/pull/97 17:44:24 grabbing ansible.netcommon next 17:52:15 what about the C() reference ? 17:52:26 I think they all still work 17:52:45 check the gist abadger1999 put up above 17:53:31 speaking of which - abadger1999 - the fQCN for modules still in ansible-base are ansible.builtin.modulename right? 17:53:32 baptistemm: C(...) is not a reference 17:53:49 samccann: yes 17:53:53 thanks! 17:54:01 samccann: I was about to ask the same 17:54:10 thanks 17:54:57 ansible.builtin is the name of the synthetic collection of modules/plugins contained in ansible/ansible 17:55:18 though I *think* the core team does not want to show this name to users, if possible 17:56:06 indeed 17:56:08 (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 I got that "with an initial C(M(!)) to specify" 17:56:40 which makes it a bit awkward that the docs for the builtin modules and plugins might display this collection name 17:56:59 baptistemm: I found that several times in community.network, I think it was copy'n'pasted from one source 17:57:10 baptistemm: I simply removed the M() part, i.e. reduced it to `C(!)`. 17:58:24 DING DING DING community meeting in #ansible-community IN TWO MINUTES! 17:58:44 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 samccann: that's what I mean with awkward :) 17:59:08 heh 17:59:22 I wonder what the core team thinks about this 17:59:50 gooood question! 18:00:50 FYI Community meeting in #ansible-community 18:00:57 just started 18:03:56 k. gonna switch over there 18:10:57 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 I wasn't really around today and yesterday, so in case this was discussed, I missed it... 18:15:02 nothing being split out yet. Doubt much will happen in that regard before 2.10 18:15:32 so 2.10 docs will be much the same as it is today, but with the collection module docs added back 18:15:33 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 :) 18:17:03 is there any current plan for that happening? As in when's the next ansible release? 18:17:17 that's a very good question :) 18:17:24 I have no idea what the current plan is for ansible-base 18:17:56 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 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 oh haha you're more in the know than I am for sure 18:19:03 I'm pretty sure that I'm not, or at least that now I know nothing more than you do :) 18:32:59 should we close out this dockathon since most of us are over in the community meeting at this point? 18:33:34 acozine: ^^ ? 18:42:21 naming of junos modules is meh junipernetworks.junos.junos_logging why don't they drop junos from module name 18:42:50 junipernetworks.junos.logging would have been better 18:44:20 When I create a PRs for M() link should I reference another issue so it can be easily tracked ? 18:47:20 for junipernetworks - the modules were already called junos_logging before the whole collection world came about 18:47:42 samccann: moving to collection does not allow renaming them ? 18:47:48 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 baptistemm: if there's an issue open in the collection, reference that 18:48:02 not if you want things backward compatible, which the network team did want 18:48:10 samccann: I'll open an issue to ask 18:48:36 yes, moving to collections does allow renaming 18:48:43 but it might break old playbooks 18:49:00 unless it's possible to add aliases for modules in collections 18:49:34 samccann: yes, I think we can close this meeting 18:49:56 acozine: I don't see any link :) 18:50:29 baptistemm the only issue I created was https://github.com/ansible-collections/community.azure/issues/4 18:50:36 baptistemm: samccann: I think some collections renamed their modules accordingly, but others didn't 18:50:58 but having a central issue might be a good idea 18:51:09 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 for all collections updates related to M() and seealso 18:51:15 I'm just not sure what repo to put that in 18:52:00 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 https://github.com/ansible-collections/junipernetworks.junos/pull/79 18:53:32 ansible-collections/overview :) 18:53:38 ah, yes 18:53:39 https://github.com/ansible-collections/overview/issues 18:53:47 I think that's currently the best place 18:53:51 okay baptistemm thanks for the PR! 18:53:58 argh too many repos 18:54:24 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 baptistemm exactly! 18:55:12 and junos use plural for module which is discouraged 18:56:17 heh, yep 18:56:51 acozine: there may already be an issue that mentions FQCN updates in that repo 18:57:20 that would be *awesome* 18:58:00 i'll check once the community meeting is over 18:58:02 too 18:58:03 much 18:58:06 multitasking 18:58:34 samccann there's https://github.com/ansible-collections/overview/issues/50 18:59:12 and https://github.com/ansible-collections/overview/issues/40 18:59:22 but neither one mentions the M() or seealso stuff 19:01:03 https://stackoverflow.com/questions/62800279/failure-in-adding-new-module-in-existing-ansible-plugin people starting to develop collection 19:01:13 "The documentation updates are not exactly exhaustive though, that's my opinion." 19:03:57 sigh 19:04:18 at least there is feedback 19:04:47 true, and maybe this AJ could join the docs community! 19:04:58 and s/he is not wrong 19:05:14 I can put an answer :) 19:05:27 baptistemm thanks! 19:05:28 https://github.com/ansible-collections/overview/issues/45#issuecomment-648405709 19:05:52 for the issue that covers seealso. there's a big ol issue for 'everything a collection owner needs to do' 19:09:48 samccann ah, that's great 19:10:26 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 I'll link to issue 45 and specifically to your comment there 19:15:52 kewl 19:18:28 https://github.com/ansible-collections/overview/issues/89 19:23:02 kewl 19:26:51 I link all PRs to there 19:27:39 thanks baptistemm !! 19:27:40 baptistemm excellent, thanks! 19:31:54 taking vyos 19:32:08 * acozine cheers 19:35:27 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 jill r mentioned one I missed in the PR and it's not in the gist 19:39:05 samccann Could you point me at which module it is? I would be interested in taking a look. 19:40:38