The title of the previous topic slightly tickled me for some reason, so I couldn’t resist re-using it.
I’ve spent the past several weeks doing a deep dive (for a newbie) into ansible with the aim of creating some new modules to fill in some gaps in the community.general.proxmox_* modules (for myself, at least - I’m not sure what may be omitted intentionally). E.g. there is a module for getting storage configurations, but not setting them. I feel like I’m now in a good position knowledge-wise to begin, but I thought I’d touch base with the community first before getting too wrapped up in my own thing.
It seems like there was some interest a year ago in moving the community.general.proxmox_* modules to a community.proxmox collection (as mentioned in the post link in the first paragraph; I also found a community.proxmox repo with a single commit forking a template repo). I’m probably in a good position to attempt that (with a little guidance on expectations). Is there still some interest in that migration and/or interest in a volunteer?
I’m also wondering how much interest, if any, there might be in upstreaming potential future modules. Some of the missing functionality feels conspicuous (like it was intentionally decided to be omitted, rather than just is currently unimplemented), but that’s just my intuition and I don’t know if it’s accurate. Is there any interest in additional modules for the official collection?
The effort to move the proxmox modules/plugins to community.proxmox was discussed last year at CfgMgmtCamp, but the folks involved found out that it was more work than they expected / had time for, and thus the project basically died before it really took off. Since then nobody stepped forward to take this up again - until now you did, I guess
Right now there are a few folks who sometimes work on the proxmox modules/plugins in community.general, as you can see from the output of git log plugins/modules/proxmox* plugins/inventory/proxmox.py plugins/connection/proxmox_pct_remote.py. So there is definitely a user base around and some hands to help, at least with smaller tasks, maybe also with larger ones (I don’t want to promise other people’s free time ).
The aim should be to get the collection in a workable state with basic CI, and to get a first release out, and soon a slightly polished one as 1.0.0.
Then we can deprecate the content in community.general and add community.proxmox to the Ansible community package, and eventually remove the proxmox content from community.general 11.0.0 (to be released in June 2025), resp. replace it with redirects to community.proxmox.
Basically from that point on the main development will happen in community.proxmox. Bugfixes added there should be re-created for community.general (since the stable-10 and stable-9 branches should still get bugfixes for some time), while PRs in community.general that are not re-creations from community.proxmox will be closed right away.
I think the main expectations are:
Implement the move, and ping interested folks (like everyone who created a proxmox related PR in community.general recently, or also folks who created issues and look interested in helping, and of course the @proxmox-collection in the forum - which you should join, if you haven’t). I’d start with forking the community.proxmox repo and figuring out how to get the history there, and once it works the Ansible community team can help taking over the community.proxmox repo and implement it there as well. (These things usually take several tries to get right, so it’s best to not do it in the real repo right away.)
Help getting CI up and running, at least a basic one. Running integration tests would be especially awesome (community.general only runs unit and sanity tests right now for proxmox content), but that is probably quite some work. (That’s why I would probably not require this for a 1.0.0 release.)
Make sure that the 1.x.y releases are (mostly) backwards compatible (with explicitly documented differences, if something isn’t backwards compatible!) to the current content in community.general, to ease migration.
At least stay around for some while to help with getting fixes and improvements merged and new versions released.
I’m sure that there are enough folks around who can help with everything, but who might not have enough time to fully work and implement one (or more) of these points.
Thanks for the detailed response, that’s helpful. I did go ahead and join the proxmox forum group.
I think I’m up for the challenge. With regard to timing, I should mention that health issues make the frequency and duration of my availability erratic. That is to say: Where timing is critical, I’m probably not the right person for the job. I’m also a bit rusty working in a team environment.
If that’s not a deal-breaker, one of the lingering technical questions I had is what should be done with shared code. In glancing through code looking for an example, though, it actually seems like the coupling might be loose enough for that to be a non-issue. There’s tight coupling to internal_test_tools, but I’m assuming that dependency can/should remain.
Otherwise, I have subscribed to the issue with the pending merge and will keep an eye out for further communication.
).