| ▲ | zeroecco 13 hours ago | |||||||||||||
Your path makes a ton of sense too! You get typed languages, state management, and the Incus team's work on the QEMU layer. The tradeoff I wasn't willing to make is the daemon + state store: Incus wants to own the VM lifecycle the way libvirtd does, and once you have that you're back to "two sources of truth" if you ever shell out. Holos is deliberately stateless on the host; Everything lives under one directory per project, rm -rf is a valid uninstall (though it will abandon the VMs if running). Different answer to the same frustration. Would genuinely like to see your thing when it's public. | ||||||||||||||
| ▲ | d3Xt3r 12 hours ago | parent | next [-] | |||||||||||||
This is exactly what I dislike about incus. But what I do like about incus is how I can easily spin up and configure VMs directly using the CLI, without preparing a config first (I hate yaml). So would be nice if holos could replicate that docker/incus CLI functionality, like say "holos run -d --name db ubuntu:noble bash -c blah". | ||||||||||||||
| ||||||||||||||
| ▲ | imiric 4 hours ago | parent | prev [-] | |||||||||||||
> Incus wants to own the VM lifecycle the way libvirtd does, and once you have that you're back to "two sources of truth" if you ever shell out. That's true. But I didn't want to reinvent what Incus or any hypervisor abstraction does. I simply wanted to add some sugar on top that allows me to easily declare infra using small abstractions, and to tie in the provisioning aspect along the way. I still use Incus directly, and can benefit from their work, as you say. State is also managed by Pulumi, so really, there are 3 places for it to exist. There are some challenges with this, of course, but I think the tradeoff is worth it. Good luck with your project, I'll be keeping an eye on it. I'll probably make a Show HN post when I release mine. Cheers! | ||||||||||||||