19:00:16 <gotmax> #startmeeting Ansible Community Meeting
19:00:16 <zodbot> Meeting started Wed Nov 16 19:00:16 2022 UTC.
19:00:16 <zodbot> This meeting is logged and archived in a public location.
19:00:16 <zodbot> The chair is gotmax. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:16 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:00:19 <felixfontein> o/
19:00:29 <gotmax> #chair felixfontein mariolenz[m] gotmax[m]
19:00:29 <zodbot> Current chairs: felixfontein gotmax gotmax[m] mariolenz[m]
19:00:39 <gotmax> #topic Intros and Info
19:00:47 * gotmax waves
19:00:48 <mariolenz[m]> I'm not sure, though.
19:00:48 <oranod> o/
19:00:48 <mariolenz[m]> o/
19:00:49 <oranod> hi everyone
19:00:55 <gotmax> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
19:01:04 <felixfontein> mariolenz[m]: yep, it should be stable-2.14. though devel is fine for now, we can update it once 7.0.0 is out and the new 8/ directory is there
19:01:15 <gotmax> acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr maxamillion: Community meeting is starting now
19:01:44 <anwesha> Hello.
19:01:45 <gotmax> Do you think we could add that ping list to the community-topics repo or something so people can add or take off their names if they want?
19:01:54 <gotmax> #chair anwesha
19:01:54 <zodbot> Current chairs: anwesha felixfontein gotmax gotmax[m] mariolenz[m]
19:02:26 <gotmax> #info Ansible 7.0.0rc1 was released this week: https://groups.google.com/g/ansible-devel/c/6qXQBecm2ag
19:02:53 <maxamillion> .hello2
19:02:53 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
19:02:59 <gotmax> #chair maxamillion
19:02:59 <zodbot> Current chairs: anwesha felixfontein gotmax gotmax[m] mariolenz[m] maxamillion
19:03:11 <gotmax> Anything in particular that people want to discuss today?
19:03:17 <maxamillion> not I
19:03:20 <felixfontein> gotmax: sounds like a good idea, especially since we should update it (anwesha is missing on it for example, and tadeboro probably wants to get removed)
19:04:02 <cyberpear> o/
19:04:36 <gotmax> Having a file in the repository might be annoying, because people would have to submit a PR to remove themselves, but meh.
19:04:42 <felixfontein> #info Ansible 7.0.0rc1 has been released! If there are no huge blunders reported until Friday, 7.0.0 will be released next week.
19:04:48 <gotmax> #chair cyberpear
19:04:48 <zodbot> Current chairs: anwesha cyberpear felixfontein gotmax gotmax[m] mariolenz[m] maxamillion
19:05:10 <felixfontein> gotmax: I guess we could also use the wiki, I don't know who can edit that though
19:05:41 <gotmax> Yeah
19:06:42 <gotmax[m]> #topic Follow Up
19:06:57 <gotmax[m]> Last week we resolved the unflatmapping issue
19:07:09 <gotmax[m]> Well felixfontein did the actual work ;)
19:07:35 <felixfontein> #info Update on private plugins in collections: core prefers metadata instead of filename semantics, I created a new PR for that (ref: https://github.com/ansible-community/community-topics/issues/154, https://github.com/ansible/ansible/pull/79370)
19:07:42 <felixfontein> wasn't that already two weeks ago?
19:07:52 <felixfontein> (or three? I'm getting old :D )
19:07:52 <gotmax[m]> Two collections have fixed the tagging issue. Many have still not responded.
19:08:06 <gotmax[m]> The unflatmapping thing?
19:08:11 <felixfontein> yes
19:08:37 <maxamillion> I honestly cant remember either
19:08:39 <felixfontein> last week the 6.0.0 release happened, the alpha release which first did unflatmapping was in the week before that
19:08:42 <gotmax[m]> Hmm, I guess it was the 2nd so two weeks ago
19:08:51 <gotmax[m]> The freeze was the 7th
19:09:27 <felixfontein> galaxy says 6.0.0-a1 was 14 days ago
19:09:59 <felixfontein> I think we discussed it at the meeting two weeks ago, and then I implemented it and released the alpha on the same evening
19:10:12 <felixfontein> (or the next morning, no idea how galaxy counts days ;) )
19:10:43 <maxamillion> always off by one surely ;)
19:10:44 <gotmax[m]> Re tagging releases: I've started working on adding a `validate-tags` subcommand to antsibull-build.
19:11:18 * felixfontein tries to remember to give it another round of review :)
19:12:10 <gotmax[m]> Hopefully, validating that releases are tagged can eventually become a release requirement just like validating depclosure did
19:12:21 <gotmax[m]> felixfontein: I still need to respond to your feedback
19:12:27 <gotmax[m]> I've been busy the past two days
19:12:57 <felixfontein> gotmax[m]: about the collections which still haven't added tags, we could start the unmaintained process for them
19:13:54 <gotmax[m]> I never posted the warnings that those collections are subject to removal if they don't fix the issue after we changed the policy
19:14:22 <gotmax[m]> But if there's already been absolutely zero response, warning them and giving more time probably won't change much
19:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
19:15:36 <gotmax[m]> We also never discussed andersson007_'s issue about collection inclusion in a meeting, but we should probably wait until he's here
19:15:59 <gotmax[m]> Also, community.network was removed from Github :(
19:16:01 <felixfontein> yes. he's on PTO right now
19:16:06 <felixfontein> yep, that sucks pretty much
19:16:24 <gotmax[m]> I found out while I was testing the validate-tags thing...
19:16:28 <bcoca> we are aware, working on it, some misunderstanding we were already aware of
19:16:31 <gotmax[m]> Wasn't there also some notice about c.g?
19:16:43 <felixfontein> interestingly they didn't remove forks of it that contain the latest content... (except the tags)
19:17:01 <felixfontein> gotmax[m]: I'm not aware of that, if you have any information please tell me :)
19:17:19 <gotmax[m]> I thought you said someone contacted you personally?
19:17:27 <felixfontein> yes, but that was about community.network
19:17:33 <gotmax[m]> Ah, nvm
19:17:40 <felixfontein> which I guess that's what now escalated to the takedown
19:18:03 <felixfontein> but I've been out of the loop (happily, I really don't like corporate threatening bullshit)
19:18:09 <mariolenz[m]> What's the problem with community.network, why was it removed? I mean, the official reason why it's been removed.
19:18:42 <mariolenz[m]> I remember some DMCA threats, but nothing in particular.
19:18:49 <felixfontein> since I don't know whether the thing I was involved in is related to the removal, I won't start guessing :)
19:19:02 * gotmax[m] sent a code block: https://libera.ems.host/_matrix/media/v3/download/libera.chat/6733488d8fd2089c6a78008b62081070951b4561
19:19:03 <mariolenz[m]> OK
19:19:31 <felixfontein> I *think* the disk quota message is wrong
19:19:56 <felixfontein> I also saw it when trying to fetch from the repo
19:20:36 * gotmax[m] thinks back to the youtube-dl mess
19:23:11 <gotmax[m]> #topic Open Floor
19:23:16 <felixfontein> :)
19:23:47 <gotmax[m]> If anyone has a larger topic they'd like to discuss, we can move there
19:24:17 <felixfontein> we could resurrect the discussion about the future of community.general
19:24:26 <gotmax[m]> People have been busy with the ansible 7 releases I guess, so there's not a lot of new stuff this week :)
19:24:36 <felixfontein> (and community.network, assuming it comes back to actual life ;) )
19:27:11 <felixfontein> or somewhat related, https://github.com/ansible-community/community-topics/issues/20 - "Process for orphaning/deprecating modules in community.general and community.network"
19:27:56 <felixfontein> the issue refers to attributes, which are now a thing (actually already have been for some time) - these could be used to mark plugins as "apparently unmaintained" without directly deprecating them
19:29:46 <mariolenz[m]> I'm sorry, but I don't have a good idea about the future of community.general :-/
19:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
19:30:02 <felixfontein> what do you think of using attributes for this (an attribute 'orphaned', where support=partial means that we're not sure whether it is orphaned, and support=full means it is orphaned and will be deprecated soon?
19:30:37 <gotmax[m]> Meh, why not:
19:31:03 <felixfontein> we could first start with all plugins that haven't received any bugfix/feature since the first commit of c.g, and keep them at support=partial for a major version, then bump to support=full, and if there's no feedback after another major release, deprecate them
19:31:07 <gotmax[m]> #topic Future of c.g and c.n and Process for orphaning/deprecating modules in community.general and community.network
19:31:08 <gotmax[m]> #link https://github.com/ansible-community/community-topics/issues/20
19:31:52 <felixfontein> so for two major versions we rely on folks looking at the docs, and if nobody cares to report that they are still interested in the plugin we deprecate it, and eventually remove it
19:32:12 <gotmax[m]> I think it'd be helpful to have data for how many modules this would actually apply to
19:32:24 <felixfontein> we should probably formulate this very nicely to not offend users who are surprised by this (for plugins which just work smoothly and never needed a bugfix or a new feature)
19:32:27 <gotmax[m]> i.e. how haven't received any bugfix/feature since the first commit of c.g
19:32:35 <gotmax[m]> * i.e. how many haven't received
19:32:37 <mariolenz[m]> "orphaned" as a state between (fully) supported and removed sounds like a good idea.
19:33:31 <felixfontein> also we might want to have different attributes, maybe one 'maintained' (support=none means it seems unmaintained) and one 'used' (support=none means we are not aware of users)
19:34:29 <felixfontein> what do you think about distinguishing between maintained and used?
19:34:47 <felixfontein> that could indicate that a module is still used, but not maintained - vs. not used and not maintained
19:35:20 <felixfontein> and folks probably mind less to say that they still use something, instead of feeling they have to commit to maintaining it to avoid it being removed
19:35:23 <felixfontein> (while it still works)
19:35:47 <felixfontein> though I wonder how we could keep these states updated over time
19:36:04 <felixfontein> all plugins have been actively used and maintained at some point - even if just at when they were merged and shortly afterwards :)
19:36:08 <russoz[m]> Morning! Catching up
19:36:14 <felixfontein> morning russoz[m]!
19:36:35 <gotmax[m]> #chair russoz
19:36:35 <zodbot> Current chairs: anwesha cyberpear felixfontein gotmax gotmax[m] mariolenz[m] maxamillion russoz
19:36:58 <felixfontein> anyway, I think attributes are a good way of indicating our current knowledge, but we still have the problem that we don't know what's actively used
19:37:04 <felixfontein> (or actively maintained)
19:37:33 <gotmax[m]> This could be interesting, but I'm not sure how many people will look at the docs and realize a plugin they use is orphaned.
19:37:58 <bcoca> should have nice big red letters ... also ansilbe-doc should have warning
19:38:09 <gotmax[m]> But I'm for anything that could help the maintainers of that collection keep track of the content and clean up dead stuff :)
19:38:52 <felixfontein> we probably need to obtain usage information somehow... maybe look at all collections and roles that had releases in the last 6 months, and have some infrastructure that marks plugins that don't show up in there as 'potentially unused'?
19:39:21 <gotmax[m]> People claim that there's a bunch of hidden dead/broken modules in c.g. without any data, so I think having that data about this would be beneficial
19:39:22 <felixfontein> or maybe even have some tool to report voluntary usage data?
19:40:28 <gotmax[m]> I'd prefer a voluntary tool or survey
19:40:43 <felixfontein> survey sounds like manual work :)
19:41:08 <felixfontein> some voluntary tool combined with some galaxy grazing (to get some base numbers) might be a good approach
19:41:08 <mariolenz[m]> There are no metrics for "used". Could be someone who uses this once every second year...
19:41:16 <gotmax[m]> gotmax[m]: A script that users could run to scan their playbooks/roles and make a list of modules that are used could work
19:41:41 <bcoca> felixfontein: vscode plugin will have telemetry (usage)
19:42:07 <felixfontein> bcoca: do they record which plugins/modules folks use?
19:42:10 <bcoca> awx/tower does not (but galaxy/AH will have indirect)
19:42:21 <bcoca> felixfontein: they are building it now, my guess, yes
19:42:45 <felixfontein> maybe we should wait and see what exactly they are developing, and see whether we can benefit from it
19:42:59 <bcoca> #ansible-devtools ....
19:43:32 <felixfontein> gotmax[m]: the hard part about such a script is getting infos on plugins other than modules and action plugins
19:43:38 <mariolenz[m]> What about issuing a warning in modules we consider as orphaned? If people don't reach out to us, we would know that we can remove it. If they do, we can still talk about how to handle this.
19:43:59 <gotmax[m]> Yeah, it'd be good to engage the devtools team in the community-topics issue.
19:44:19 <felixfontein> such information is a lot easier to gather for ansible-core itself (which knows exactly which plugins it really uses)
19:44:23 <gotmax[m]> felixfontein: True, but it'd be better than nothing
19:44:52 <felixfontein> mariolenz[m]: emitting warnings is a very unfriendly way of collecting that information IMO, we should only do that after trying to figure that out in other ways
19:45:09 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
19:45:50 <gotmax[m]> Emitting warnings would be effective but intrusive
19:45:51 <felixfontein> such usage information can also be useful for other collections
19:46:42 <bcoca> ansible-core and awx/tower will  not have telemetry, even optional ... most users really don't like having a 'spy' on their systesm
19:47:16 <bcoca> vscode seems to be an exception since they already have it for most ... also reason why i dont use it and there is OSS alternative w/o telemetry ...
19:47:30 <bcoca> vscodium (for those that want to know)
19:47:33 <felixfontein> bcoca: I fully agree on that! I'm mainly saying that it's easiest for ansible-core to hand out that data :)
19:47:56 <bcoca> yes, its a lot easier and many times we wish we had it builtin  ... but the downside is too big
19:47:57 <felixfontein> since for other programs you have to reimplement parts of core to find out that information
19:48:21 <bcoca> you CAN create a 'telemetry' callback for users to opt in, bu tthen you also need a service to capture the data
19:48:27 <felixfontein> bcoca: would it maybe be possible to have an option that dumps a YAML with used plugins for a playbook run?
19:48:31 <gotmax[m]> I strongly agree with bcoca
19:48:54 <felixfontein> a callback doesn't know which test/filter/lookup/vars/... plugins are used
19:49:29 <bcoca> felixfontein: it can, has access to full task, but was thinking of making strategy to do 'requirements dump' ... also for syntax check  and 'dry run'
19:51:21 <felixfontein> bcoca: but it doesn't know which plugins were used when templating something that an action plugin templates (because it doesn't know when an action plugin does some templating)
19:52:16 <mariolenz[m]> felixfontein: In our environment, you won't get any telemetry data about the modules we use. And I think there are a lot of similar environments. So while emitting warnings might be crude, I think it's more efficient.
19:52:17 <mariolenz[m]> Anyway, I don't consider warnings as generally "very unfriendly". It depends on how you phrase it ;-)
19:52:18 <mariolenz[m]> them
19:52:54 <bcoca> felixfontein: it can, just has to ask plugin loader
19:53:50 <gotmax[m]> Too many warnings can lead to warning fatigue and/or people disabling warnings all together. I think it would be useful to employ warnings, but it should not be the first thing.
19:54:44 <felixfontein> one could also use ansible-lint for that, i.e. have it emit warnings if plugins are used that are marked as orphaned, instead of emitting such warnings at runtime
19:54:50 <bcoca> ^ why we eneded up removing 'warn' from shell/command
19:55:51 <mariolenz[m]> felixfontein: Only helps where people use ansible-lint...
19:56:18 <felixfontein> mariolenz[m]: true :) I don't know how often it is used
19:56:19 <mariolenz[m]> It's a good idea, though, but only additionally imho.
19:56:37 <bcoca> anything outside of bultinto ansilbe-core std runs will be a 'subset' of user base, had this discussion many times and there is no 100% way to get good usage numbers
19:56:52 <bcoca> roles on galaxy  + issues against modules are the best aprox we currently have
19:57:05 <felixfontein> mariolenz[m]: also you can always use a staged approach, start with less intrusive warnings, and eventuall resort to 'real' warnings / deprecation if there hasn't been any reports before
19:58:34 <felixfontein> bcoca: I think it's nice to have better approximations than that, but it's always clear we won't have prefect data
19:59:36 <felixfontein> anyway, thanks for discussing this :)
20:00:07 <mariolenz[m]> Yep, sounds like a good approach. Document modules as orphaned (and maybe add checks to ansible-lint), try to get usage metrics, then start to issue warnings and finally remove the module. But I think that issuing warnings is important.
20:00:38 <felixfontein> definitely! I just would try to get information in other ways first :)
20:00:48 <gotmax[m]> It's 2:00. Does anyone have anything pressing to say before we end off?
20:00:49 <gotmax[m]> Well, it's 2:00 here :)
20:02:21 <gotmax[m]> #info There is some agreement about identifying and removing dead/unmaintained/unsed plugins in community.general and community.network.
20:03:01 <felixfontein> here it's 21:02 ;)
20:03:02 <gotmax[m]> #info Ideas include: adding metadata about the maintenance state of plugins, announcing orphaned plugins in the changelog/bullhorn, maybe some sort of optional survey/script/callback plugin to collect data, warnings after time has at once, engaging the devtools team about data from ansible-lint or the vscode plugin
20:03:09 <samccann1> heh
20:03:19 <samccann1> here it's 21:03!
20:03:35 <felixfontein> and ... in a minute, it will be 21:04!
20:03:41 <gotmax[m]> 14:02 if you wish
20:03:54 <felixfontein> samccann1: are you travelling?
20:03:55 <samccann1> as another longshot statistic... I can gather website hits on specific modules to see who is looking at the docs
20:04:04 <samccann1> no, just lost track of time
20:04:12 <felixfontein> hehe ok :)
20:04:19 <samccann1> and used yours to say I was one minute later
20:04:19 <felixfontein> yeah, we could also incorporate docsite hits
20:04:24 <gotmax[m]> #endmeeting