Ok, I tried creating a cluster.
I have 2 computers.
One is running arch and has incus 0.7 installed, the other is running Ubuntu 22.04.4 and is using that zabby repo , stable version which is version 6.0.0.
When trying to join the cluster I got
Error: Failed to join cluster: Failed request to add member: The joining server version doesn't match (expected 0.7 with API count 387)
Of course, I expected something like that.
How do I get v0.7 on Ubuntu 22.04? Or better the same version arch has installed.
If you only have two computers, you might be better off not clustering and just using remotes.
The cluster expects the systems to be the same and always online.
If you want to try anyway, then you can pin the version you want on the Ubuntu machine with the right apt command. A quick search should show the syntax.
But 6.0.0 seems to be the LTS version.
How can I pin something that is further ahead of something that seems to be the highest possible version from that repository?
What even is the 0.7 version? Which git hash does it reference?
That’s 0.7
Can I maybe go install github.com/lxc/incus@0.7?
… But then again Go version is outdated on ubuntu, and Go v1.22 is masked as incompatible because of some sigsev issue with older kernels.
I’ve added, to /etc/apt/preferences.d/incus
Package: incus
Pin: version 0.7*
Pin-Priority: 1000
But that did nothing.
Why I want a cluster is because I’d like to use the webui to manage those 2 machines.
Why I went with incus is because libvirt is ok but I have to manually download the images and also can only use cloud images in a very complicated way.
I’d like a nice easy to use web UI or desktop app where I can create VMs or containers of different OSes.
And speaking of webui.
I’ve installed the incus-cannonical-ui arch package and pointed nginx to the directory, but it’s “not working”. But that’s a topic for another thread.
The best option would be an incus-lts package on arch.
I have a few minutes and will try to find a solution for your version pinning topic.
If you get the cluster running, it still might not work the way you are envisioning. Normally, you would need at least three machines for the cluster to work the way it is designed. There are algorithms built into the system that don’t make sense with two machines.
For your use case it might work anyway. Are you planning on keep both machines turned on and off at the same time? Having one turned off while the other one is running can cause the cluster to think that the off machine is dead.
Now let’s see about that version pinning. I am curious to see how it works.