I think I’ll be looking at adding a incus-ui-canonical package or something along those lines to my repository which would then get you the LXD UI, quite possibly with a few minor edits to fix the branding, links and command line instructions it gives you.
Should anyone else have a usable web UI for Incus, I’ll be happy to package it too, then users can just install whichever one they want on their system!
Yeah, there wouldn’t be any legal issue there, obviously the fork would have to remain under GPLv3 but that’d be fine.
I don’t think any of us on the Incus team enjoy web development enough to go through the whole process of starting and maintaining a fork of the LXD UI, but that’s why I’m currently planning on just taking the LXD UI as it is, just do minimum rebranding through a couple of simple patches and then ship that through my package repository.
If someone wanted to invest a bunch of time and effort into maintaining a full fork, that’d obviously be fine too.
I am very pleased that the LXD UI works with Incus, because this means that the Incus and LXD REST APIs are still mostly compatible. I hope it remains so. You had indicated here not to count on such compatibility and you specifically mentioned that “For the lxd-to-incus migration tool, we import both the incus and lxd clients in the same binary, specifically so we don’t rely on the incus client to talk to LXD or vice-versa.”
I would like to see more things being compatible between LXD and Incus. There may be other tools besides the LXD UI that could work in both products. I develop such a tool and I use it to launch LXD and Incus containers the same way. I resorted to writing my own API with the things that I need from each product, and implemented it for Incus and for LXD using their respective Go packages.
Comparing api/instance.go between Incus and LXD, I see that they differ mostly in comments. The LXD version has comments that include “LXD” and “lxd”, while the Incus version has more generic terms:
// InstancePut represents the modifiable fields of an instance.
// InstancePut represents the modifiable fields of a LXD instance.
One more substantial difference is the deprecated LXD ContainerOnly field, that has been removed from Incus. This means that instance.go cannot currently be shared between the two products in Go. But the JSON representations of the instance.go types are still compatible between Incus and LXD. Is there, or can there be a specification of the API that both products can adhere to?
I did contact Canonical at the beginning of the Incus work to inquire about willingness to switch to the generic terms so that code could be more similar between both projects. I was told the request would need to be escalated and I have not heard anything since, so I wouldn’t hold my breathe about the likelihood of shared code/initiatives at this point.
I would like to use it, though the way of CLI creating certificate and adding trust for that in a browser is not seriously an easy and perhaps less safe way of managing a whole lxd host/cluster.
Till a better authentication solution is provided, including a Role Based Access such as Openfga etc. I would consider it as a tool for a one-man show.