Yes… I have checked them both, but they are not like a serious client like the one for KVM, or other hypervisors (VMWare, Citrix Xen, etc…)
I meant if there were any future plans on the LXD roadmap to have a GUI client. As I mentioned… I am happy with the terminal, but I have found it difficult for non linux oriented people to get a hold of it.
@erik_lonroth yes I am actively developing this, thanks! I have not built anything for juju yet so I am not sure what development there would require. The lxd-dashboard is a simple LAMP based application so I imagine building it to work with juju would be straight forward.
That is wonderful that it works out of the box with juju. Currently there is only the local user authentication system in the dashboard. I have been considering expanding that with ldap. I will do some research on candid to see what that may offer too.
I have good experience with pylxd , python , async , wedevelopment and system skills . I am curretnly jobless so i would like to work on full time on it if anyone can chip in.
I am frustrated with proper gui for lxd , LXDUi is featureful many done badly.
I would like to build and maintain a proper LXD Management UI in Python + Svelte. I had build one for a client’s Learning Managemnt system where it have common features of LXD already in place ( Starting , Stopping , Creating , Saving Images as templates , cloning , directly proxying instances via nginx) : only missing is websocket LXD Terminal Shell.
I could build one and maintain properly since i have time.
Did you see my post above with all the other existing dashboards?
Also there is 0 to no money in just writing a dashboard, all the existing ones do a “good enough” job really - we all have the same API’s after all. If your looking to make money your better of writing an application based on LXD IMO, yet another dashboard is probably just going to waste 1 or 2 years of your life (unless you have some killer feature you haven’t yet posted).
I could imagine, we can build up something.
I don’t really agree on that. It is, as long as you don’t aim to be the first to implement every bit LXD does.
LXD aims to be able doing everything, you need to decide which part is unnecessary from a commercial point of view.
Toss those unnecessary expensive gadgets, improve the others and complete through your own code.
People used to AWS, Azure… What they don’t offer, customers don’t know and even don’t want, why bother killing your resources and offer nonsense for free?
Docker took off, because it is humble and not dominant in every concept. It doesn’t aim to take control of your host, resources, networks and be the all-in-one tool to go.
One reason could be the whole plan for LXD to promote snap, juju, maas …
I was in a funny mood when I wrote this but I some what stand by it.
A dashboard is typically holds no opinion or workflow and covers the standard series of actions (CRUD instances, terminal access, maybe some RBAC).
“Products” typically offer an opinionated workflow on things, like
Creating “projects” and issuing a invoices / billing
I.E a cloud provider in a box
Products for data science / Research institutes
Products for educational settings / workflows
Support for the opinion your providing
Perhaps I was abit negative in my response to @v3ss0n but what I was really suggesting is that ‘Yet another dashboard’ is not a complete suggestion. What is should have said is, what is this dashboard going to-do than none of the others do? Or is the USP simply a new frontend?
Docker is a great case study because the whole community was horribly offended when they started to charge for the desktop app, people dont want to pay for the basics.