Would it be possible to add LXD container support to OVS-Toolbox also?

[bmullan]

Just thought I'd ask if there would be any possibility to add LXD container support for OVS-Toolbox?

There is a Python library for interacting with the LXD REST API: https://github.com/lxc/pylxd

What is LXD? LXD: Introduction

PyLXD API Documentation: http://pylxd.readthedocs.io/en/latest/

[bmullan]

I guess I should have added this information...

The LXD Development team has announced & is currently working to add Virtual Machine (VM) support to the LXD "system" Container environment.

By this the LXD Daemon would support MANO (Management & Orchestration) of both LXD containers and libvirt VM's on both Local and Remote Server/Hosts running LXD.

So supporting the LXD REST API by OVS-Toolbox would in the near future be capable of doing the same!

For info on the LXD VM development work see this: https://github.com/lxc/lxd/issues/6234

Brian

[nbonnand]

Just thought I'd ask if there would be any possibility to add LXD container support for OVS-Toolbox?

Thanks Brian for your interest in OVS-Toolbox and for your interesting links.

Would you believe it or not, support for LXC containers was something I was having in mind for a while. :-)
And this is going to be my priority for OVS-Toolbox next release !

REST API may not be that useful in my case, because I am already using a lot ssh in OVS-Toolbox and will try to reuse my existing code as much as possible. ( Anyway thanks for mentioning it, it's good to know. )

I just need to experiment a bit with LXC/LXD features.
I understand that LXD was built on top of LXC, but I don't yet understand what are the limitations of this model.
What if someone runs a 'classic LXC' container ? Can he manage it with LXD commands or will it be invisible for LXD ? ( And what about the opposite ? )
Are LXC classic and LXD containers incompatible ?

Ideally, I would like to write some code that would work for whatever container ( LXC classic or LXD ), but my first tests are a bit disappointing. ( I ran two containers on the same host. A classi and a LXD. "lxc-ls" only listed my classic LXC container and"lxc list" only listed my LXD container. I was expecting/dreaming to be able to see both of them with just one command.... :-( )

[bmullan]

@nbonnand

Nicolas

For any LXD/LXC questions I would suggest asking on the Forum as that is where the LXD/LXC developers interact on Q&A daily: https://discuss.linuxcontainers.org/

However, thanks for the reply.

Maybe this post in Mar 2018 by Stephane Graber (project lead for LXD/LXC) will help.

https://discuss.linuxcontainers.org/t/directions-and-roadmaps/1300

stgraber
Stéphane Graber
Maintainer
Mar '18

So in general, we (as in Canonical LXD team) will be focusing on:

Developing LXD
Maintaining liblxc (the C library that LXC provides)
Maintaining go-lxc (the Go binding for liblxc)
Maintaining our image generation tooling (distrobuilder & jenkins)

We will happily do code reviews, give pointers, suggestions and help with design for the remaining components but as those aren’t critical to what we’re delivering, we won’t spend much time working on those ourselves:

lxc-utils (the traditional C tools)
lxc-templates (old shell image generation scripts)
python3-lxc (python3 binding for liblxc)
python2-lxc (python2 bindings for liblxc)
lua-lxc (lua bindings for liblxc)
ruby-lxc (ruby bindings for liblxc)

LXC using the C tools still has its uses, it’s daemon-less, allows for completely unprivileged containers (those started from an unprivileged user) and is also well suited for embedded environments due to its lack of daemon and very small footprint.

We expect most traditional users of LXC to migrate to LXD as it offers a better experience in general and allows for more powerful use of containers, but those who have special needs for the traditional LXC experience (HPC users, embedded users, …), those can and I expect will stick to the C tools.

We have no plans to deprecate liblxc, in fact, we’re planning on moving some of the LXD features into it, to make them faster and available to users from C. We also will keep building a wide variety of images and keep adding new exciting features to LXD. That’s the focus of the containers team at Canonical, but other contributors have other priorities so I still expect a lot to happen in those other parts of the project.