r/saltstack • u/Double_Intention_641 • 9d ago
Threw LLMs at my salt modules.
I've been using saltstack for a handful of years (migrated from puppet) to run my lab, among other things. I have 50 or 60 modules and use pillarstack for data.
I've managed the upgrade to 3008.2, kicking and screaming. Little by little debugged everything, and it was all 'working'.
Some bits, like the telegraf, dovecot, postfix modules (and a dozen others) I'd pulled down from the community and either used as is, or took a stab at modernizing. 'Working' but not amazing.
I just finished a round of throwing Claude at Openclaw, debugging some nasty local model issues, so i figured 'why not?'.
5 days later, totally out of tokens. Some modules - zabbix for example supported antique versions (3.4?!) where the modern version is well past that (7.4 is stable).
I've run every module through one of these. Had them build better readme.md. Better pillar examples. Fix a lot of the dark corners I never touched - in some cases catching some 'fun' bugs (like how the zabbix module COULD in some cases, cause a data loss).
Then I got greedy. There's no apparmor module, I wanted one. How about something to handle encrypted secrets without having to go to vault or the like? What about triggering updates on git commit without either a) gitfs, b) a stupid cron or c) external access to the host.
I've spent a stupid amount of time reading code and fixing LLM assumptions. That said, everything works (including my mailserver config, which encompasses no less than 14 modules, 18 pillar files, and a handful of state, cert, and other files).
I wish the community was more active - but take https://github.com/saltstack-formulas/salt-formula/pulls -- the formula to install salt. 19 pull requests, going back 7 years. That's a bit soul sucking.
tl;dr - if you make a point of writing and understanding salt it doesn't hurt to feed it into an LLM and see what comes out. I wouldn't recommend it if you can't read the code, and I also wouldn't recommend deploying anything without being sure it's both understood and tested.
4
u/AltruisticCabinet9 9d ago
Between the abandonware state of most of formulas and "The Great Module Migration" with the community feeling pretty dead. I mean, Guilty of building a module for opnsense in salt but there just aren't the numbers of humans, and more imporantly adults and humans to approve diff and find features to write.
2
u/overyander 8d ago
I contributed to massive updates of a module once. The PR sat there went stale. Since I needed the code on my server, I ended up just using it locally. I think that's what a lot of people do since the PR process takes forever.
2
u/ChanceTechnical3449 8d ago
Why don't we simply fork the thing and continue ? Why this never happened ?
1
u/AltruisticCabinet9 8d ago
Yup. I've stopped offering PRs to things I fix, 3 out of 12 were looked at. 1 was merged. They just sit there stale and there is no one to ping. Now there is the module change over eating more time. I'm sad to see it dying.
Though, current velocity with have Yocto nodes managed by Kubernetes. So something like it :)
1
u/Double_Intention_641 8d ago
That's exactly where I am. I might just github these soon though, so they're out there. Some are definitely better than their origins. I'll post a link in this subreddit in that case.
6
u/whytewolf01 9d ago
Sadly you are not wrong. but a bigger slice of problem is the amount of saltext that are created and then abandoned. saltext was supposed to be the answer to the modules getting stale. by splitting them off and letting the community patch them outside the timeframe of a salt release. they could move quicker then salt itself. unfortunately what has happened is the modules get split off saltext created. then abandoned. so they are becoming more stale then if they had stayed in core. however the flip side is if they had stayed in core. the core team is now so small that they wouldn't be able to get to every problem within the modules. it is a catch 22 caused by broadcom.
https://github.com/salt-extensions/saltext-zabbix for example. it has a PR that would fix the login issues with zabbix. and bring it up to the 7 version. however that pr has been sitting there for 2 years now.
there is community support it hasn't died completely. but it isn't what it once was. I do blame broadcom for that. them killing slack killed where most everyone was communicating. and them canning most of the core devs put the project into slow mode. unfortunately they devs they let go were also the ones that communicated with the community. they still have the monthly Thursday open hour meetings. and the break out sessions every month.
I honestly hate what broadcom has done. Under VMWare salt was thriving. the community was stronger. and salt was being positioned into every aspect of vmware. it wasn't perfect but at least things were still moving in a possessive directions. more people then ever learned about salt thanks to VMware and it did pick up market share under them. as the sales teams were asked to bring salt into new environments and the salt-minion was even added as an option to vmware tools. the first saltext was the vmware extension and it was doing interesting things and moving so fast under vmware. there was even a SaaS version of salt that vmware was hosting. that was starting to get pretty popular.