18:09:00 <samccann> #startmeeting Community Working Group
18:09:00 <zodbot> Meeting started Wed Jul 19 18:09:00 2023 UTC.
18:09:00 <zodbot> This meeting is logged and archived in a public location.
18:09:00 <zodbot> The chair is samccann. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:09:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:09:00 <zodbot> The meeting name has been set to 'community_working_group'
18:09:11 <samccann> @room meeting time!
18:09:25 <samccann> Raise your ascii hand (o/) to say hi or any other way you want to let us know you are here. And Welcome to any new folks!
18:09:31 <samccann> Agenda: https://github.com/ansible/community/issues/679 / Topics: https://github.com/ansible-community/community-topics
18:09:38 <briantist> o/
18:09:45 <briantist> oh hay, I'm kinda around
18:10:11 <samccann> #chair briantist acozine jtanner bcoca
18:10:11 <zodbot> Current chairs: acozine bcoca briantist jtanner samccann
18:10:14 <samccann> welcome welcome
18:10:21 <samccann> #topic Updates
18:10:26 <Leo[m]> o/ hi all. Late but here.
18:10:31 <samccann> #info docs lift n shift basically done - https://github.com/ansible-community/community-topics/issues/243
18:10:32 <dansou901[m]> o/
18:10:47 <samccann> Not sure if we need to keep that issue open a bit longer or if the SC has the rights they were looking for
18:10:52 <acozine> #chair dansou901 Leo briantist
18:10:52 <zodbot> Current chairs: Leo acozine bcoca briantist dansou901 jtanner samccann
18:10:55 <samccann> #chair Leo dansou901
18:10:55 <zodbot> Current chairs: Leo acozine bcoca briantist dansou901 jtanner samccann
18:11:06 <felixfontein> o/
18:11:15 <acozine> #chair felixfontein
18:11:15 <zodbot> Current chairs: Leo acozine bcoca briantist dansou901 felixfontein jtanner samccann
18:11:57 <samccann> hmm in theory we have 9 issues marked as next meeting - https://github.com/ansible-community/community-topics/issues?q=is%3Aopen+is%3Aissue+label%3Anext_meeting
18:12:07 <samccann> some are a bit old so let's start at the tope
18:12:26 <felixfontein> I don't think that this label is still used accurately
18:12:35 <samccann> ooo you're here!
18:12:41 <samccann> #chair felixfontein
18:12:41 <zodbot> Current chairs: Leo acozine bcoca briantist dansou901 felixfontein jtanner samccann
18:12:46 <samccann> wanna take over?
18:13:23 <felixfontein> I'm only half-way here, feel free to continue :)
18:13:31 <samccann> we can start with the matrix room one - https://github.com/ansible-community/community-topics/issues/258
18:14:09 <samccann> Gist of it is - some matrix work has to happen before the end of the month due to ...changes...
18:14:29 <samccann> so all rooms with an irc bridge like this one will be impacted
18:14:49 <samccann> the IRC folks shouldn't see any change
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:03 <samccann> matrix users will see this room die and have to go to a new room
18:15:22 <maxamillion> .hello2
18:15:24 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
18:15:30 <samccann> #chair maxamillion
18:15:30 <zodbot> Current chairs: Leo acozine bcoca briantist dansou901 felixfontein jtanner maxamillion samccann
18:15:32 <acozine> I hope the "this room is gone, go HERE" message will stay visible for a long time
18:15:35 <samccann> welcome welcome
18:15:46 <samccann> I'm unclear on that one sadly acozine
18:16:20 <felixfontein> acozine: my guess is that it would stay indefinitely
18:16:27 <maxamillion> wait, why do we need to create new matrix rooms?
18:16:28 <samccann> I don't know if the 'this space has moved' message just sits here in this room, or if you don't see it until you try to post here.  I should have listened better
18:16:30 <Leo[m]> acozine: I have seen that happen a few times, but didn't time it sadly.
18:16:40 * maxamillion is trying to catch up
18:16:48 * acozine needs to check all the rooms she's in
18:16:48 <felixfontein> the last time it was just there
18:16:51 <Leo[m]> But I did get an issue where for some reason, I wasn't moved... and the message was there when I returned
18:17:13 <samccann> maxamillion: it's a matrix thing. Gwmngilfen could fill in the blanks but there were two ways to create rooms and most of our rooms with bridges were created in the way that matrix is deprecating at the end of the month
18:17:26 <bcoca> gist: there is an issue with current 'linking tech' used between matrix and irc, freenet is forcing the change to fix the issue of quality of service on their side, requiring matrix side to change how they link to rooms
18:17:41 <felixfontein> bcoca: s/freenet/libera/ ;)
18:17:42 <samccann> ah thanks bcoca for the details.
18:17:44 <bcoca> using an already existing alternative
18:18:00 <Leo[m]> samccann: ^ libera actually is the one deprecating, but our Matrix rooms can't be migrated from one bridge
18:18:01 <bcoca> yes, sory, libera.net aka people fleed from freenet ...
18:18:33 <samccann> all links etc will still work, but those of us in these rooms today, will be redirected to the new rooms.
18:19:03 <felixfontein> bcoca: that one was called freenode ;)
18:19:40 <felixfontein> freenet is (or was) another unrelated IRC network
18:19:46 <samccann> do we want to go to dansou901 's issue next?
18:20:01 <bcoca> tyoo sober to remember
18:20:04 <samccann> #topic role arg_spec order
18:20:19 <samccann> #link https://github.com/ansible-community/community-topics/issues/253
18:20:32 <maxamillion> ohhhhhhhhh ... can't migrate :/
18:20:33 <maxamillion> ugh
18:20:38 <felixfontein> this one requires core involvement, and probably first a proper proposal - especially if it should also cover plugins and modules
18:20:43 <felixfontein> (cause of docs fragments
18:20:44 <felixfontein> )
18:21:11 <felixfontein> the good thing is that it's less intrusive than semantic markup, so it is possible to get that done faster :)
18:21:33 <dansou901[m]> yeah, can you move/convert it to a proper proposal then?
18:22:50 * samccann not sure where proposals live now?
18:23:58 <felixfontein> yeah, that's the next part... :) I guess currently still https://github.com/ansible/proposals/, at least the ones that affect core
18:24:18 <samccann> bcoca: does that sound correct ^^ ?
18:24:18 <felixfontein> but then there will be the new discussion forum somewhen (soon?), which will be a better place for proposals
18:24:28 <samccann> also true
18:25:47 <felixfontein> maybe first asking more general - what do folks think of the idea? of module/plugin/role authors being able to force a specific order for the options, and/or being able to group them?
18:26:33 <felixfontein> right now you can only 'group' by common prefix (since all options are ordered alphabetically)
18:26:35 <samccann> I still worry about deviating from alphabetical order, but can understand via dansou901 how that forces some parameters 'apart' so to speak when reading the docs etc.
18:26:47 <felixfontein> and that's more like 'grouping', since there's no clear boundary between one group and the next
18:27:27 <felixfontein> for example, one module where grouping would make sense is community.crypto.x509_certificate: https://docs.ansible.com/ansible/latest/collections/community/crypto/x509_certificate_module.html
18:28:06 <felixfontein> separating the provider-specific options (entrust_*, ownca_*, selfsigned_*) from the generic ones would make the docs better readable IMO
18:28:39 <felixfontein> (to have an example of a non-role where this could be useful)
18:28:44 <samccann> yeah I could see that
18:29:10 <bcoca> samccann: order is not set by core afaik
18:29:32 <samccann> so the collection owner would decide if the docs would appear alphabetically or by what is in the arg_spec, and alphabetical would be the default?
18:29:41 <bcoca> ansible-doc does sort hwen presenting, but should not affect html
18:29:54 <felixfontein> bcoca: ansible-doc sorts alphabetically when showing the text version, and also the JSON output is sorted alphabetically
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:16 <bcoca> we can 'unsort' the json, no issue, its just that way for readability
18:30:28 <samccann> bcoca: the question is would that proposal repo still be the place to present this idea since I'm assuming it changes code somewhere to label whether to go by alphabetical or argspec for example
18:30:45 <felixfontein> samccann: I don't really like the idea of allowing unsorted
18:31:08 <bcoca> ^ i agree, i see little value for sort orders other than alpha
18:31:11 <samccann> not sure what 'unsorting' is in this regard? I thought we were talking alphabetical or by arg_spec?
18:31:27 <felixfontein> unsorted = as specified in YAML in the argument spec
18:31:39 <dansou901[m]> I would propose to allow grouping, but do alphabetical sorting inside the groups
18:31:49 <bcoca> ^ not really, but close, depends on python implementation, it is a dictionary
18:31:56 <felixfontein> I prefer that proposal
18:31:56 <bcoca> so sometimes it will be 'python order'
18:32:04 <bcoca> not yaml defined order
18:32:24 <samccann> felixfontein: ah my bad... thought the 'grouping' was the argspec order...
18:32:28 * samccann zips lips
18:32:34 <felixfontein> bcoca: since Python 3.6 or something like that python order == source file order, so for all non-EOL versions of ansible-core it would be source file order, or not?
18:32:51 <bcoca> as i said 'depends on python'
18:33:14 <bcoca> 3.6 and 3.7 are supposed to be like that .. but i would not trust anything < 3.8
18:33:32 <felixfontein> ansible-core 2.13+ requires Python 3.8+
18:33:50 <felixfontein> (2.12 and before are EOL)
18:34:07 <bcoca> i know ... and yet i see 2.9 all over ...
18:35:06 <bcoca> in any case, its not something core will probably work on, but would not be against PR if it comes up to 'toggle ordering in json output'
18:35:56 <samccann> I think the question is - do we need to move this community-topic to a core proposal? We don't want the eventual PR blocked after someone does all the work so to speak?
18:36:17 <felixfontein> bcoca: the proposal will be likely more complex, and not involve the dict order in JSON output
18:36:20 <bcoca> <= really only one that reads propsals
18:36:21 <samccann> or do I just put a comment in the community topic that says 'bcoca sez go for it' :-)
18:37:01 <bcoca> im saying 'im not doing it, but not opposed to a reasonable PR that implements it'
18:37:50 <felixfontein> the current proposal somehow allows the argspec author to group options, in a way that isn't defined yet (and probably needs to know about docs fragments, so this will be a bit more intrusive change)
18:37:52 <dansou901[m]> I am sorry, but I won't be able to do it, exceeds my python knowledge.
18:38:05 <bcoca> also saying .. i really don't see the need for it, so a use case would be nice
18:38:14 <felixfontein> I'm happy to implement it, but first we need to know *what exactly* to implement :)
18:40:01 <dansou901[m]> my use case involves roles where I do a lot of nesting which make the parameters hard to follow when grouping isn't allowed
18:40:22 <felixfontein> do you have a (public) example of such a role?
18:41:14 <bcoca> add_fields( ... sort_order='alpha'): ...
18:41:26 <dansou901[m]> It's on our internal network, sorry. I could post a fragment here
18:41:32 <bcoca> for o in sorted(fields, sorting ...)
18:43:09 <bcoca> key=func,  funcs would have to be predefined
18:43:20 <bcoca> alpha func(x): return x
18:43:48 <bcoca> origin(x) : return None
18:44:17 <dansou901[m]> options:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/c4c99a1001410753de06968eb3a7dfaffd6ac023>)
18:44:18 <bcoca> but dont see how we do not hardcode the sorting optoins
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:43 <felixfontein> dansou901[m]: the grouping I'm thinking of would only work on the top-most level
18:45:50 <bcoca> dansou901[m]: seems like a nesting issue more than a sorting one
18:47:02 <dansou901[m]> I could flatten the options, but wanted to have them the same way they are printed out in the resulting config file
18:47:17 <bcoca> also .. suboptions are not sorted ?
18:47:18 <dansou901[m]> that's why I'm doing the nesting here
18:47:29 <bcoca> you only have 1 option .. so really sorting is not the issue here
18:47:56 <dansou901[m]> suboptions are sorted, that's the issue
18:48:22 <bcoca> not in my output
18:48:48 <felixfontein> bcoca: at least --json output also sorts subkeys, and the HTML output also does it
18:48:59 <dansou901[m]> if I run antsibull-docs, they are sorted
18:49:23 <bcoca> should fix ansilbe-doc to sort normal output too ...
18:49:23 <felixfontein> antsibull-docs sorts them alphabetically
18:50:05 <felixfontein> bcoca: I thought ansible-doc text output is also sorted
18:50:17 <bcoca> json.dumps(structure, cls=AnsibleJSONEncoder, sort_keys=True, indent=4)
18:50:30 <bcoca> felixfontein: for options, yes, ... seems suboptions are not
18:50:55 <bcoca> ^ json dump would sort even if not presorted
18:51:02 <felixfontein> bcoca: they should also be, since add_fields() calls itself recursively
18:51:16 <felixfontein> bcoca: and add_fields() uses sorted() in its main loop
18:52:40 <bcoca> he, it helps if you correctly spell optoins ...
18:52:46 <bcoca> options!@!Q!!
18:52:48 <felixfontein> :)
18:53:10 * bcoca goes to corner and dons 'dunce hat'
18:53:45 <briantist> sorry I got distracted
18:53:56 <bcoca> i am distracting ...
18:54:01 <briantist> I added a pretty concrete example in the issue bcoca
18:54:28 <briantist> most of my plugins/modules have a lot of options that come from docfrags/module_utils, and would highly benefit fromg rouping
18:54:31 <briantist> grouping*
18:55:06 <bcoca> that is more of a case for a 'auth plugin/struct' that modules/plugins could consume
18:55:08 <samccann> about 5 min left to the meeting
18:55:36 <briantist> similar to (what I think) Felix said, I don't like the idea of arbitrary ordering of individual options, but I do like the idea of grouping options (and they can be alphabetical within there)
18:55:50 <bcoca> something liek the 'providers' that network modules once attempted
18:55:56 <briantist> it's not just auth
18:56:14 <bcoca> you can already group, just make em suboptions of the 'group'
18:56:21 <briantist> and it's not related to ansible auth either, so I think arbitrary grouping based on context makes more sense
18:56:28 <bcoca> i.e auth: [name, secret, key]
18:56:44 <briantist> suboptions don't work in plugins to take advantage of env vars, ini, vars, etc.
18:56:53 <bcoca> how so?
18:56:58 <briantist> (or do they? I have the feleing you're about to tell me I'm wrong lol)
18:57:28 <briantist> in any case, suboptions is not really what I'm looking for
18:57:55 <felixfontein> suboptions should work fine with env vars, ini, vars etc... but they are more annoying to use especially for lookups
18:58:02 <bcoca> well talking about roles and modules .. that is one clear way to 'group' things, dont really think we need another
18:58:21 <bcoca> felixfontein: most plugins do not support suboptions, modules/roles do
18:58:44 <felixfontein> bcoca: isn't the config manager supporting it?
18:59:46 <briantist> I think this is a documentation/presentation issue mostly, suboptions is awkward and changes the way you author and use roles/plugins/modules, so it seems a poor choice to me
19:00:18 <bcoca> felixfontein: not afaik
19:00:33 <bcoca> one of the reasons to migrate from config manager to args_spec was suboption support
19:00:59 <felixfontein> hmm ok
19:01:03 <felixfontein> anyway, I have to go now
19:01:06 <felixfontein> see you everyone, and thanks!
19:01:11 <bcoca> i mean .. you can setup documenattion that looks like it, but it wont be processed or validated aside from 'its a dict'
19:01:24 <samccann> Thanks felixfontein
19:01:35 <samccann> anything else before we end the meeting?
19:02:40 <samccann> felixfontein: ok thanks!
19:02:47 <samccann> #endmeeting