18:00:41 <felixfontein> #startmeeting Ansible Community Meeting
18:00:41 <zodbot> Meeting started Wed Apr 19 18:00:41 2023 UTC.
18:00:41 <zodbot> This meeting is logged and archived in a public location.
18:00:41 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:41 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:42 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/679
18:00:42 <felixfontein> Landrash[m], acozine, andersson007_, anwesha, ascherbaum, baptistemm, bcoca, briantist, cidrblock, cyberpear, cybette, dericcrago, dmsimard, felixfontein, geerlingguy, gotmax, gundalow, gwmngilfen, ikhan_, jillr, jtanner, lmodemal, mariolenz[m], markuman, maxamillion, misc, nitzmahone, oranod, resmo, russoz, samccann, thaumos, wbentley15[m], zbr: The Ansible community meeting is starting
18:00:47 <felixfontein> now!
18:00:50 <felixfontein> The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself.
18:00:53 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/679 / Topics: https://github.com/ansible-community/community-topics
18:00:56 <felixfontein> #topic Updates
18:01:04 <gotmax23> .hi
18:01:04 <zodbot> gotmax23: gotmax23 'Maxwell G' <maxwell@gtmx.me>
18:01:14 <gotmax23> oranod: thanks!
18:01:21 <acozine> o/
18:01:23 <felixfontein> #chair gotmax23 acozine
18:01:23 <zodbot> Current chairs: acozine felixfontein gotmax23
18:01:28 <cybette_> o/
18:01:40 <felixfontein> #chair cybette_
18:01:40 <zodbot> Current chairs: acozine cybette_ felixfontein gotmax23
18:02:23 <felixfontein> anyone else around today? :)
18:02:30 <felixfontein> otherwise it will be a small, cozy meeting :)
18:03:10 <gotmax23> #info Version 0.56.0 of antsibull, the ansible package build tool, was released today (https://github.com/ansible-community/antsibull/blob/main/CHANGELOG.rst#v0560). This deprecates support for building ansible versions less than 6 and removes a broken test.
18:04:14 <acozine> Nice!
18:04:26 <gotmax23> We're also working on v2 of antsibull-docs and the antsibull-core library used by both antsibull-docs and antsibull.
18:04:27 <gotmax23> * antsibull-docs and v2 of the antsibull-core
18:05:31 <gotmax23> ansible-core 2.15.0b3 was released this week. Is another ansible 8 alpha planned?
18:06:52 <felixfontein> we did say something about every two weeks, but the first alpha was a week late, so I'm not sure what happens now
18:07:03 <gwmngilfen-work> I'm just passing, so apologies for being offtopic (and don't chair me) - I'll have website and forum development updates for you tomorrow. Ran out of time today :)
18:07:05 <felixfontein> roadmap: https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_8.html#release-schedule
18:07:15 * felixfontein waves to gwmngilfen-work!
18:07:28 <Leo[m]> hi all
18:07:50 <felixfontein> #chair Leo[m]
18:07:50 <zodbot> Current chairs: Leo[m] acozine cybette_ felixfontein gotmax23
18:07:54 <gotmax23> #info The netapp.aws collection looks unmaintained (https://github.com/ansible-community/community-topics/issues/223). It's subject to removal from Ansible 10 as per the Collection Removal policy (https://github.com/ansible-collections/overview/blob/main/removal_from_ansible.rst#unmaintained-collections).
18:08:19 <gotmax23> I'd say we should release another alpha this week
18:09:09 <felixfontein> sounds reasonable. I don't know whether anwesha[m], chadams[m] or whoever else can do this have time for it though
18:11:16 * gotmax23 is checking what collections have been updated in the meantime
18:11:18 <acozine> it would be nice to get back on schedule
18:11:28 <gotmax23> indeed
18:11:45 <felixfontein> :+1:
18:12:23 <felixfontein> gotmax23: regarding antsibull-core 2.0.0, should we do a 2.0.0a2 release soon, or even today?
18:12:46 <gotmax23> yeah, I think that makes sense
18:13:10 <gotmax23> I'm not sure there's any other breaking changes we need to get in
18:13:16 <gotmax23> And I think we've waited long enough :)
18:13:25 <felixfontein> we can still do more breaking changes after a2 ;)
18:13:34 <felixfontein> (we did some after a1 as well IIRC)
18:13:40 <gotmax23> that's true
18:14:26 <gotmax23> it'd just be nice not to have to release too many alphas
18:14:34 <gotmax23> do you want to do the antsibull-core release or should I?
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:01 <felixfontein> I can try it... shouldn't be too problematic :)
18:15:14 <felixfontein> anyway, does anyone have some topics to discuss for today?
18:15:48 <gotmax23> FTR, here are the changed collections since the last alpha 🙂: https://paste.sr.ht/~gotmax23/51910c674fc3e52a39d9ee5917c1e2b11c12105f#8.0.0a2.diff
18:16:05 * gotmax23 checks the topics
18:17:18 <gotmax23> I don't see anything new besides https://github.com/ansible-community/community-topics/issues/224
18:17:54 <gotmax23> As for my other issues, I'm not sure how we should move forward with the CLA one and I don't have any updates about the release blocker one.
18:18:08 <gotmax23> We discussed the CLA issue a bit last week
18:18:30 <felixfontein> 224 is something russoz[m] and me already discussed, I wanted to dig out these discussions and link to them :)
18:18:46 <felixfontein> that was in the context of adding EE support to community.general
18:18:57 <gotmax23> 👍️
18:19:30 <felixfontein> it would be nice to have a machine-readable way to specify all kind of requirements, so that one could write a module / action plugin that allows to install them automatically on localhost or a remote target
18:19:51 <felixfontein> (our discussion was about specific modules / plugins, but I guess you could also have a similar mechanism for whole collections)
18:19:57 <gotmax23> indeed
18:20:05 <AndreasadsScherb> felixfontein: Makes sense, yes.
18:20:07 <gotmax23> However, I'm not sure I like either of these approaches
18:20:14 <felixfontein> I actually wanted to play around with that, but then suddenly semantic markup started moving again and since then I'm basically busy with that :)
18:20:37 <gotmax23> Ansible collections aren't Python packages so using python metadata isn't appropriate
18:20:50 <gotmax23> requirements.txt isn't granular
18:21:05 <gotmax23> I'm not sure how the core team would feel about adding things on to galaxy.yaml
18:21:17 <felixfontein> I don't think requirements.txt or galaxy.yml is a good idea
18:21:24 <gotmax23> I think we need some sort of custom format
18:21:54 <felixfontein> I would probably put it in DOCUMENTATION for the plugins/modules (then you can also use docs fragments) and have it in some kind of YAML format
18:22:37 <felixfontein> and for the whole collection, a YAM file in meta/ is probably a good idea with a similar / the same format as would be used in DOCUMENTATION (for individual plugins/modules)
18:23:23 <felixfontein> for meta/, there's still nitz's proposal https://github.com/ansible-community/community-topics/issues/154#issuecomment-1464590465, and my ideas for that: https://github.com/ansible-community/community-topics/issues/154#issuecomment-1465108005
18:23:43 <gotmax23> For Python packages, it can just be a list of Python dependency specifications, but we'd also need to the freeform field for system packages and other misc requirements.
18:23:44 <felixfontein> (unfortunately there was no further discussion of either of these ideas...)
18:23:55 <felixfontein> freeform is a very bad idea
18:24:04 <felixfontein> we already have `requirements:` for that, and it sucks :)
18:24:53 <felixfontein> I would probably have a list of alternatives with conditionals (depending on playform/arch/...), so that you can have a fine-grained list of dependencies for different situations
18:25:12 <felixfontein> sometimes you might want to use Python packages from the system repos, sometimes you want them from PyPI, depending on the platform/arch/...
18:26:09 <felixfontein> and potentially you want to even give the user some freedom of choice
18:28:02 <felixfontein> I guess we have to find a compromise between to strict and too flexible, and we need to check whether something fitting already exists that we can use (instead of reinventing the wheel)
18:28:05 <gotmax23> that sounds like a great idea. e.g,the libselinux bindings cannot be installed from PyPI even though it's a Python package (it should be the distro python-libselinux package), but e.g. jmespath doesn't require special handling
18:28:28 <gotmax23> What about bindep that's used by EEs?
18:28:41 <felixfontein> bindeps are really limited
18:28:54 <felixfontein> I noticed when trying to create one for community.sops... :)
18:29:14 <felixfontein> (I ended up creating an installation role that you can run in the EE setup process...)
18:29:26 * gotmax23 remembers
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:17 <felixfontein> for many things having a combination of requirements.txt + bindep.txt is probably fine, but there are always exceptions :)
18:30:49 <felixfontein> and requirements.txt doesn't allow to say "only install this for RHEL < 9, since we want to use the version from the system packages for RHEL 9+"
18:30:55 <gotmax23> We could have the docs field be a list of dictionaries with a name field, a type field (system or python) and then a when field that uses the same conditionals that ansible uses (such as ansible_distribution or ansible_os_family).
18:31:28 <felixfontein> yes, something like that would work
18:32:14 <felixfontein> that would even allow you to react on user-provided variables (like allow user to define sops_prefer_github_over_system_repos=true to avoid installation from system repos even if available)
18:32:33 <gotmax23> right
18:33:32 <gotmax23> I'm not sure that allowing arbitrary keys is the best idea though
18:33:45 <gotmax23> Maybe it'd be better to limit it to set list of allowed keys such as distribution, os_family, architecture, and pkg_mgr
18:33:54 <felixfontein> I would probably have `python` and `system` list of strings in there, instead of a type field; and basically the rules would be "go through the list of dicts until the first found whose 'when' conditions match"
18:34:09 <felixfontein> yeah, that's a good question
18:34:30 <felixfontein> it's definitely better to restrict it in the beginning, and possibly extend it later
18:34:51 <gotmax23> I want it to be easy to parse/determine when something should be installed by other tools
18:35:48 <felixfontein> :+1:
18:36:08 <gotmax23> Having a standardized format would present some interesting opportunities for automation in Fedora ansible collection packaging, so I'm all for this proposal 😃
18:36:15 <felixfontein> :)
18:37:00 <felixfontein> I think it would be very useful in general, and solve many of the common support problems when users report that something doesn't work even though they installed the requirements (usually on the wrong machine, for the wrong Python, wrong user, ...)
18:38:07 <gotmax23> indeed. there's a lot of different things for which we could use this data.
18:39:05 <felixfontein> I guess the three big questions are: 1) how much should this be supported by core? (if it is in DOCUMENTATION then validate-modules should at least have minimal support by not disallowing it) 2) where does the tooling live (some collection? core?) 3) who 'controls' the format?
18:39:17 <felixfontein> ah, and where exactly is it stored ;)
18:42:51 <felixfontein> one could later also have tools that for example make sure that the deps of all modules used in a playbook / role are installed
18:44:46 <gotmax23> that would be very useful IMO
18:45:02 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:09 <felixfontein> parts of the earlier discussions are here btw: https://github.com/ansible-collections/community.general/issues/4512
18:45:33 <felixfontein> I'm not sure how many of the other ideas were also discussed somewhere, or just part of discussions I imagined ;)
18:45:38 <gotmax23> I'm not sure who should control the format. It might be nice to have this in core, but there's a higher barrier to get that in
18:45:58 <gotmax23> btw, I added a quick comment to https://github.com/ansible-community/community-topics/issues/224
18:47:07 <felixfontein> also if its in core, development will be a bit glacial since you can only have new features every half a year ;)
18:47:53 <felixfontein> well, anyway, I think it's good to discuss this somewhat further and eventually try this out (as a prototype) to see how it works
18:47:59 <gotmax23> that brings us back to the discussion about ext metadata. do we have a place to put this if it's not used by core?
18:48:28 <felixfontein> so far, no
18:48:58 <felixfontein> or well, we can add random new files, but there is no way to guarantee that core (or someone else) will never use the same filename for something else
18:49:50 <gotmax23> and what about module documentation? we can't add arbitrary keys to DOCUMENTATION either, can we?
18:50:25 <felixfontein> well, we can, but with the same caveat... and the problem that ansible-core's sanity tests will complain about it if there is no explicit support
18:50:47 <utoddl[m]> project-wide guidelines for development of experimental features? Rather like "-x" http headers, but for files?
18:50:52 <felixfontein> (just minimal support that simply allows a specific key to have arbitrary values would help for that, though, and that might be possible to get)
18:51:08 <felixfontein> #chair utoddl[m]
18:51:08 <zodbot> Current chairs: Leo[m] acozine cybette_ felixfontein gotmax23 utoddl[m]
18:51:34 <felixfontein> utoddl[m]: right now there are none, I think, but https://github.com/ansible-community/community-topics/issues/154#issuecomment-1464590465 and my follow-up comment have some ideas for that :)
18:51:36 <gotmax23> right, but I don't think that's super sustainable in the long term
18:52:12 <gotmax23> so I guess we now have two issues to follow up on async 😃
18:52:21 <felixfontein> just two? ;)
18:52:32 <gotmax23> s/two/two more/
18:52:35 <felixfontein> ;)
18:52:59 <gotmax23> open floor time?
18:53:28 <felixfontein> #topic open floor
18:53:36 <dericcrago> is anyone attending PyCon in person this weekend?
18:53:44 <felixfontein> #chair dericcrago
18:53:44 <zodbot> Current chairs: Leo[m] acozine cybette_ dericcrago felixfontein gotmax23 utoddl[m]
18:53:46 <felixfontein> hi dericcrago :)
18:53:55 <felixfontein> (I don't, I didn't even know it is this weekend...)
18:54:05 <dericcrago> hi felixfontein :)
18:54:18 * gotmax23 won't be there
18:55:24 <gotmax23> felixfontein: re antsibull-docs v2 what else is missing for 2.0.0a1?
18:55:26 <felixfontein> me neither; dericcrago I guess you will go?
18:55:53 <felixfontein> gotmax23: mainly an antsibull-core 2.0.0a2 release, and adjusted dependencies to require that one
18:56:05 <gotmax23> ack
18:56:10 <dericcrago> planning on it, thought I'd see if anyone else was going to be there too :)
18:56:24 <felixfontein> for 2.0.0 I'd like to have 1.0.0 of antsibull-docs-parser (and antsibull-docs-ts) out
18:57:16 <felixfontein> dericcrago: I wouldn't be suprised if some more are; today a lot of folks aren't around for this meeting, so :shrug:
18:58:25 <gotmax23> btw, I plan to work on an antsibull-build --version command and support for automatically determining the python_requires and Programming Language :: Python :: classifiers for ansible (community package) based on ansible-core's metadata
18:58:29 <Leo[m]> dericcrago: We could probably mention something in Bullhorn if you are planning to be there? an improvised meetup for those attending, cybette what do you think?
18:59:25 <cybette_> I think there are some people from Ansible engineering going, although we don't have a booth or anything. would be nice to mention it in the bullhorn I guess
18:59:38 <cybette_> although it's already starting
18:59:42 <cybette_> might be too late
19:00:41 <felixfontein> ok, thanks everyone for the discussion! (feel free to continue to talk here once the meeting is over :) )
19:00:44 <felixfontein> #endmeeting