For a while, I’d been looking for a good CLI tool to manage my Proxmox clusters without writing Ansible playbooks or logging into SSH as root. I couldn’t find one, but I found a very nice library for interacting with the Proxmox API.
The only “problem” with this is that it’s not a CLI tool, but rather an API written for/in the Go programming language
I never really wrote anything serious in a compiled language before, but Go seems pretty easy, and very useful! And honestly it’s probably about the only way I’ll see a good CLI tool for Proxmox.
So that means lately I’ve actually been focusing a lot of my time and efforts on learning golang.[^1]
but first,
The frustrating thing about gomox is that such a tool needs to be written in the first place. Proxmox just doesn’t really have much in terms of third-party tooling, although the deeper I get into its internals the more I start to understand this: it’s a whole lot of crusty Spaghetti Perl.[^2] Maybe that’s being a little unkind/unfair, but it’s definitely not super easy to follow, and so there just hasn’t been a whole lot of community tooling. And what is around can be pretty bare.
And now that I’ve been working with the API for maybe a week, the API has had a silly breaking change occur.
I didn’t actually notice this in my own use so far (maybe I updated my servers after updating the library?), but it’s a little disappointing!
And despite Proxmox’s open-source development model and decent popularity, collaboration and development coordination takes place over old-school, Kernel-style mailing lists, which is more than a little frustrating to contribute to…
Maybe it’s a generational thing, but the Pull Request workflow is so easy to work with! I don’t think every open-source project should centralize on GitHub, but Gitea is a great FOSS forge compatible with the workflow popularized on GitHub.
All of this and sometimes I start to question if I really want to stick with Proxmox. But the likes of libvirt don’t supply the same powerfully simple clustering out-of-the-box. And of course VMware is very non-free!
Harvester (and kubevirt) seem fantastic, but they would barely function on my smallest servers!
Incus (and LXD) are much closer to what I like about Proxmox, but I fear that it would still be both heavier and less useful out-of-the-box than Proxmox…
So at least as it stands now, I’m making my own tooling around Proxmox, by way of Go.
enter
gomox is my attempt to build a CLI application for manipulating Proxmox virtual machines.
gomox is also my first serious project written in a compiled language, as well as my first remotely serious attempt at Software Development™ so it’s naturally pretty incomplete and probably what does work is really buggy!
But my real goals here are as follows:
Build a useful CLI tool for working with Proxmox, suitable for scripting and interactive use.
Build a relatively simple tool for bootstrapping Fedora CoreOS virtual machines by supplying an ignition file, which I currently plan to do by (ab)using Cloud-Init features.
Learn some useful programming skills
4….make friends and connections?!
Side goal: build a CLI tool that’s compatible with Proxmox’s own qm tool, using Tteck’s Proxmox VE Helper Scripts for compatibility testing.
(That’s probably the biggest and most complex third-party project using the qm tool directly.)
If my content has been helpful to you, please consider buying me a coffee or
