I am using LXD mantually , and most of light weight LXD GUI admins are unmaintained , so i am thinking about going heavyweight and use OpenStack. I had tried openstack on KVM with KVM instances … very high resource consumption.
I read a few here and there , mostly outdated blogs where Openstack used LXD containers instances instead of KVM.
Is there any good guide regarding that ? had anyone tried? I am going to do that on new server setup.
I don’t think the nova LXD integration is supported anymore.
There is a list of LXD GUIs here:
I don’t think the nova LXD integration is supported anymore.
Ah , thats sad , what happened with openstack ? A quick glance seems that they rolled their own Container manager called ZUN . And there is another thing called Magnum which supports Docker Swarm/Kubernetes .
Never heard of it! It seems dead-ish, or at least not a good idea for production at this time.
I think LXD Containers can still be used in Openstack both as Service Nodes and Compute Nodes
https://docs.openstack.org/charm-guide/latest/admin/ha.html
For instance in the above Document there are Notes like:
Note
When a LXD container is the targeted machine, its zone is inherited from its host machine.
Not all of Openstack’s service nodes can be run in LXD containers but many can.
Brian
Thanks checking out , and thinking about trying Openstack , installed inside LXD.
HA setup seeems to be super complex with lxd. I just want LXD as compute containers.
OpenNebula is a great cloud toolset and supports LXD
The OpenNebula Community Edition is free to use I believe:
What Is OpenNebula Community Edition — OpenNebula 6.2.2 documentation
its total resource hog , i would just bite complexities of kubernetes configuration and use it.
All LXD need to shine over alternatives like openstack / nebula is to have a good managment UI.
everything else can be done with juju + lxd / ansible + lxd
LXD is a lot more lighterweight than competaitors and it gets things done.
@sean i had checked around nova-lxd repos and all of them (one on launchpad and one on their home repo) are dead , no upates since 2018 , even bug tracker oly have 40 bugs and 3 new bugs are 2019 . so it seems no one use it.
Furthur research show that LXD effort was abandoned and they are working on ZUN , but Libvirt supports LXD and can be configured in OpenStack with it.
Interesting.
you could try the
nova libivirt dirverwithvirt_type=lxcor zun instead
Ref : https://lists.openstack.org/pipermail/openstack-discuss/attachments/20190810/e73e217e/attachment-0001.html
Whats your problem with all the existing UI’s? LXDMosaic had a new tag like 2 weeks ago and LXDWare Dashboard had one a few months back.
I dont buy the “unmaintained” line so you’ll have to express what your problems are. You dont want user accounts? You want to be able to do Iaac? What?
Offtopic I think. and whats wrong?
I tried lxdmosiac once and it cannot connect to unix socket . and i haven’t looked back.
I tried LXDUi and it is not async - blocking when multiple developers working at the same time .
Based on the below its not off topic (which btw there are years of work in the existing GUI’s they aren’t “unmaintained”)
As to
I’m trying to understand what you want this GUI todo, that others dont already do, without beating around the bush.
Off topic: LXDMosaic can and does work with the socket (its auto connected now in the SNAP), if not I dont see an open issue 
.
Just now i tired and still won’t let me connect. I tried with curl and unix socket replies .
testing on Arch Linux.
This is off-topic, I’ve openeded an issue here but after 30 mins of arguing with arch I simply refuse to, If you guide me how to get a setup running ill try to debug it.
For anyone reading this - its a SNAP limitation.
OP has LXD installed via AUR which uses the socket path /var/lib/lxd/unix.socket which any SNAP cant access, maybe @stgraber can ask snapd team to autoconnect? (Its an Arch specific thing)
The link I posted has some workarounds but nobody can solve OP’s problem if they are using SNAP.
Dear GUI authors: you will need to support installation on “every” (Arch) OS natively to use the socket (or one of the work around’s I purposed in the link).