So unlike LXD, Incus doesn’t plan on having a default web UI.
Instead, I’m now updating the packages that I’m making to allow for simply serving whatever is found in /opt/incus/ui/ as the web UI when someone accesses Incus from a web browser.
That means that any web UI which is just a bunch of html/javascript/css can then be dumped in that folder and Incus will serve it.
As a quick test, I copied the lxd-ui from the latest edge build of LXD and here’s the result:
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.
If you are actively developing/maintaining an Incus compatible web UI and would like to have it packaged in my repository, let me know or better yet, send a pull request!
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.
A central piece of the API is the Go package github.com/lxc/incus/shared/api for Incus and github.com/canonical/lxd/shared/api for LXD. I wish parts of this package could eventually be shared between the two projects and become a sort of common API (like the S3 API which is shared across many products).
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.
LXD UI is a modern API client so it already was staying away from the bits of API that was removed in Incus, leaving the main differences to be around deprecated config keys and the like which was simple enough to patch in place. There are a few more differences around types for things like the server config (incus is map[string]string, lxd is map[string]any because of trust_password), but that kind of difference is invisible in javascript.
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.
Rather than generating a new cert, is it possible to put an LE certificate somewhere that the (Incus) UI will be able to use it? I looked through the Incus documents and those of, um, the original project and it wasn’t clear where. Or do you insist on a private cert, which I’d rather not do?
