LXD is no longer part of the Linux Containers project

[Stéphane Graber]

Original: https://linuxcontainers.org/lxd/

Hello,

Canonical, the creator and main contributor of the LXD project has
decided that after over 8 years as part of the Linux Containers
community, the project would now be better served directly under
Canonical’s own set of projects.

While the team behind Linux Containers regrets that decision and will
be missing LXD as one of its projects, it does respect Canonical’s
decision and is now in the process of moving the project over.

Concretely, the expected changes are:

- https://github.com/lxc/lxd will now become https://github.com/canonical/lxd
- https://linuxcontainers.org/lxd will disappear and be replaced with
a mention directing users to https://ubuntu.com/lxd
- The LXD YouTube channel will be handed over to the Canonical team
- The LXD section on the LinuxContainers community forum will slowly
be sunset in favor of the Ubuntu Discourse forum run by Canonical
- The LXD CI infrastructure will be moved under Canonical’s care
- Image building for Linux Containers will no longer be relying on
systems provided by Canonical, limiting image building to x86_64 and
aarch64.

What will not be changing:

- The rest of the Linux Containers projects remain unaffected
- The image server, currently used by both LXC and LXD will keep
operating as normal, though with less architectures available as
mentioned above

Those changes will likely all happen pretty rapidly as everything is
relatively tightly integrated together. As a result, you may notice a
bit of bumpiness while Canonical sets up the replacement
infrastructure.

Sincerely,

The Linux Containers team

Christian Brauner
Serge Hallyn
Stéphane Graber

[Saint Michael]

This is a terrible problem that makes almost impossible to use the advantages of Vmware infrastructure to host Linux Containers (LXC)

Unless you set the vmware switch to promiscuous mode, which is not allowed in most companies, the following networking modes don't work

macvlan, veth,

so we can only use phys, and that is subject to the max possible number of network interfaces, 10, which leaves the max number of containers to 9 per virtual machine.

This is because we need all containers to have a different mac address and public IP.

One possible solution is networking=vepa, but Debian and Ubunto do not support it. 

Is there a way to solve this riddle?

 

[Narcis Garcia]

I suspect the lack of LXD on Debian repositories was already a symptom
of separate project's strategy.
And why does it depend on "snap" daemon? This is a lack of integration
on host OS and lack of distro packagers revision to stable and trusted
versions.

Luckily, time ago I ported some tool from OpenVZ management to manage
LXC and not depend on LXD.


El 5/7/23 a les 3:41, Stéphane Graber ha escrit:

--

Narcis Garcia

__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

[Alex Clarke]

Agreed. Saw this coming a mile away. Can't imagine the snapd push and non-ubuntu distro separation/politics that caused would have been fun to manage. Doesn't make it any less disappointing to see this hit my inbox. 

Thanks for all your work Stéphane and team - it's a sad day to see people so obviously passionate as you leave the project.

[Nicolas FOURNIL]

So this is the end ...

Your job was really impressive, I have run your software in production since 2015 on 100+ production containers without any major problems... but since Canonical got the project, it has never been the same (gasp).

Clearly Canonical has ambition to become a Redhad/Windows hybrid (and perhaps wants to be buy by Micr$oft) : Snap and especially the SnapStore (not opensource, not able to control precisely updates, and no local version -airgap is a joke!- ) have finish to push me far away from Ubuntu/Canonical !

The port of the LXD in Bookworm WITHOUT Snap was really interesting for me. So we stay in our new architecture (based on bookworm) with LXD and kick off canonical and snap stuff.

No you leave... I hope you find another adventure better than Canonical. I hope for me to get an alternative to LXD :-/

Best regards.

Nicolas F.

--
You received this message because you are subscribed to the Google Groups "lxc-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lxc-users+...@lists.linuxcontainers.org.
To view this discussion on the web visit https://groups.google.com/a/lists.linuxcontainers.org/d/msgid/lxc-users/CA%2Benf%3DuCcTkSb0PcbV%3D-sW7F06exS0rUeQjuzF%2BU7anG1ye7-g%40mail.gmail.com.

[Tamas Papp]

hi Stephane,

It is unclear to me, what will change for the users practically.

You mentioned two things:

- The project will be hosted by Canonical (changes of URLs).

- Fewer architectures of LXD images will be available.

Who is going to remain the developers (contributors) of the project? Concretely, are you going to keep working on it? Is the development going to remain open?

What advantages does Canonical expect from this change?

If the information can be published, what particular problem triggered the change?

How does this change influence the future of the roadmap and plans?

Thanks in advance,

tamas

[Marcin Szewczyk]

On Wed, Jul 05, 2023 at 01:41:42AM +0000, Stéphane Graber wrote:
> - The image server, currently used by both LXC and LXD will keep
> operating as normal, though with less architectures available as
> mentioned above

This is unfortunate. Just a couple of days ago I said to my friends how
easy it was to create a build server for a 32-bit Debian environment in
minutes.

I hope that Canonical won't oracle the project as a whole.

--
Marcin Szewczyk
http://wodny.org

[Narcis Garcia]

I was near to move from LXC to LXD, but I still keep with LXC-only
because of this sort of dependencies.

I use debootstrap to generate any container.


El 5/7/23 a les 18:04, Marcin Szewczyk ha escrit:

Narcis Garcia

[Stéphane Graber]

On Wed, Jul 5, 2023 at 1:02 AM Linus Lüssing <linus.l...@c0d3.blue> wrote:
>
> Hi,
>
> Thanks for forwarding the news. Not ment judgingly but to better understand
> how things like this can happen. Can I also read this as follows?
>
> 1) Many/most of the LXD contributors/developers
> (by code contributed) personally would have liked the LXD project
> to stay more independent, under the non-profit linuxcontainers.org
> umbrella, as it used to be so far.

Yes

> 2) Canonical('s management?) wants more control over LXD? (or what is Canonical's
> motivation?) Which contradicts 1).

Yes, Canonical upper management wanted more control.

> 3) However the Linux Containers team can't decline
> because otherwise they'd risk their own ties with / job at Canonical?
> (Or what would be at risk if things were just kept as is?
> Trademark enforcement from Canonical, which would then require a rename of LXD?
> And/or Canonical cutting its funding for development on it?
> (which would seem contradictory to 2) then though) )

Canonical owns the trademark on LXD so refusing the request could
indeed have been a bit tricky.

> Sorry, if a casual, very uninformed bystander like me is completely
> misreading this. But this announcement at least had me raise an
> eyebrow and gave me a bit of mild OpenOffice/Oracle tingles.
>
> Regards, Linus
>
> PS: I love using LXD and really appreciate all the work and effort
> you guys have put into it. And was glad that I could contribute a
> little once by debugging and narrowing down one small issue with
> LXD + systemd-networkd in the past. But maybe that's also why this
> news made me a little bit concerned.

[Stéphane Graber]

On Wed, Jul 5, 2023 at 3:18 AM Narcis Garcia <debia...@actiu.net> wrote:
>
> I suspect the lack of LXD on Debian repositories was already a symptom
> of separate project's strategy.
> And why does it depend on "snap" daemon? This is a lack of integration
> on host OS and lack of distro packagers revision to stable and trusted
> versions.

Not really, the snap was a legitimately good way for an upstream
project like LXD to reach a very very wide audience by only doing one
package.
Most other projects entirely depend on per-distribution packagers
which causes a lot of lag and complexity when debugging problems.
For all its fault (walled garden, difficulty managing at scale, ...),
the snap ecosystem is very very convenient for upstreams.

Now Debian 12 ships LXD natively as a deb in its repos, the same goes
for Alt Linux, ArchLinux, Alpine, Gentoo, OpenSUSE and a number of
others who all have native (non-snap) packages for LXD.

> --
> You received this message because you are subscribed to the Google Groups "lxc-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lxc-users+...@lists.linuxcontainers.org.

> To view this discussion on the web visit https://groups.google.com/a/lists.linuxcontainers.org/d/msgid/lxc-users/451c5b58-6de0-ecfe-fa3f-88481d1fc019%40actiu.net.

[Stéphane Graber]

On Wed, Jul 5, 2023 at 5:22 AM Tamas Papp <tamas...@rtfm.co.hu> wrote:
>
> hi Stephane,
>
> It is unclear to me, what will change for the users practically.
>
> You mentioned two things:
> - The project will be hosted by Canonical (changes of URLs).
> - Fewer architectures of LXD images will be available.
>
> Who is going to remain the developers (contributors) of the project? Concretely, are you going to keep working on it? Is the development going to remain open?

The Canonical LXD team will keep working on it. These days it's a set
of around 10 people with more positions opened to be filled.

As you may have seen since, I have left Canonical:
https://stgraber.org/2023/07/10/time-to-move-on/

I may still contribute to LXD here and there, but I'm no longer the
project leader.

LXD will keep on as an Open Source project (Apache-2), there's no
planned change on that front at all.
How open the development community will be, that may or may not
change, it's up to Canonical from now on.

> What advantages does Canonical expect from this change?

Control

> If the information can be published, what particular problem triggered the change?

My resignation from the company

> How does this change influence the future of the roadmap and plans?

It shouldn't affect it. Everything I presented as planned for the next
6 months remains on the company roadmap.
I had relatively little LXD work assigned directly to me so my
departure shouldn't cause items to be skipped.

> To view this discussion on the web visit https://groups.google.com/a/lists.linuxcontainers.org/d/msgid/lxc-users/CAJgZx%3D%2BAxogU7jm8pkm-YLq6dk%2BLHa2W2fLxgZxGHBf%3DpsDqPQ%40mail.gmail.com.

[Narcis Garcia]

El 12/7/23 a les 3:02, Stéphane Graber ha escrit:

> On Wed, Jul 5, 2023 at 3:18 AM Narcis Garcia <debia...@actiu.net> wrote:
>>
>> I suspect the lack of LXD on Debian repositories was already a symptom
>> of separate project's strategy.
>> And why does it depend on "snap" daemon? This is a lack of integration
>> on host OS and lack of distro packagers revision to stable and trusted
>> versions.
>
> Not really, the snap was a legitimately good way for an upstream
> project like LXD to reach a very very wide audience by only doing one
> package.
> Most other projects entirely depend on per-distribution packagers
> which causes a lot of lag and complexity when debugging problems.
> For all its fault (walled garden, difficulty managing at scale, ...),
> the snap ecosystem is very very convenient for upstreams.
>
> Now Debian 12 ships LXD natively as a deb in its repos, the same goes
> for Alt Linux, ArchLinux, Alpine, Gentoo, OpenSUSE and a number of
> others who all have native (non-snap) packages for LXD.
>

A similar experience I had and I imagine for this case: A single Debian
version (6) came natively with OpenVZ. After this, next OVZ steps walked
to less integration in any OS.

This made me migrate to LXC.

As more and more a project follows standards, it's easier to integrate
it to more OS distributions. All work done on integration capabilities,
makes software mature, strong and flexible for anyone.
This is the reason to me for choosing LXC but not LXD yet.

Regards;
Narcís.

[Harald Dunkel]

On 2023-07-12 03:02:13, Stéphane Graber wrote:
> On Wed, Jul 5, 2023 at 3:18 AM Narcis Garcia <debia...@actiu.net> wrote:
>>
>> I suspect the lack of LXD on Debian repositories was already a symptom
>> of separate project's strategy.
>> And why does it depend on "snap" daemon? This is a lack of integration
>> on host OS and lack of distro packagers revision to stable and trusted
>> versions.
>
> Not really, the snap was a legitimately good way for an upstream
> project like LXD to reach a very very wide audience by only doing one
> package.

I am using LXC since 2011 (AFAIR) for builds and tests and production,
and I am very happy with it, but if there had been native Debian packages
I would have switched to LXD years ago. I made some bad experience with a
snap package (!= LXD), but more important is that these snaps are not on
the blessed path to run Debian systems.

Anyway, thank you very much for your good work on both LXC and LXD.


Regards
Harri

[Saint Michael]

My entire company runs on LXC. I couldn't be happier.

I hope that this extraordinary technology does not die out because of Canonical.

--
You received this message because you are subscribed to the Google Groups "lxc-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lxc-users+...@lists.linuxcontainers.org.

To view this discussion on the web visit https://groups.google.com/a/lists.linuxcontainers.org/d/msgid/lxc-users/d82d8ea6-f9bf-edb4-a476-4b7c0f604779%40aixigo.com.

[Nicolas FOURNIL]

I cannot agree with you : Snap is good for desktop, that's true. But for production environment it's catastrophic :

- my servers are isolated from internet : "snap way of life" is not possible.

- It's also not possible to let canonical do remote upgrade on a running system : before update there's validation on each environment !

- for replayability : you cannot rebuild a running snap from scratch (what exactly is inside ?)

- you cannot own your snap store and stay far away from USA (just in case...)

For these reasons snap IS NOT DESIGN for Server critical use, but for desktops.

That's why I go far away from Ubuntu now (and more : security updates... for subscribers !) 

To view this discussion on the web visit https://groups.google.com/a/lists.linuxcontainers.org/d/msgid/lxc-users/CA%2Benf%3DtwkGtYKhAN5qMjtBCViPbU1LSOir4naUQxG6o%2BHhfzZA%40mail.gmail.com.

[Stéphane Graber]

On Sun, Jul 16, 2023 at 3:55 AM Nicolas FOURNIL
<nicolas...@gmail.com> wrote:
>
> I cannot agree with you : Snap is good for desktop, that's true. But for production environment it's catastrophic :
>
> - my servers are isolated from internet : "snap way of life" is not possible.

The snap proxy allows for fully airgaped environments in much the same
way you'd normally handle with a package mirror.
For simpler setups that don't need an enterprise-wide solution,`snap
download`, `snap ack` and `snap install` works fine for offline
systems.

> - It's also not possible to let canonical do remote upgrade on a running system : before update there's validation on each environment !

The snap proxy allows for enterprise-wide control of what revisions
are being pushed, allowing for such validation pre-rollout.
Outside of using the snap proxy, you can use `--hold` which will
prevent any automatic refresh of a snap, effectively giving you the
same behavior as apt.

> - for replayability : you cannot rebuild a running snap from scratch (what exactly is inside ?)

That may be true for some snaps, for the LXD snap however as it's
included in Ubuntu, the same requirements on re-buildability and on
the source being fully public exists as for debs.
In the case of the LXD snap, its source has always been available in
the lxd-pkg-snap repository, nowadays at
https://github.com/canonical/lxd-pkg-snap
The build is also all happening publicly with links to relevant source
and build log: https://code.launchpad.net/~canonical-lxd/+snap/lxd-latest-candidate/

Again, it's not something that all snaps HAVE to do, but it's
something that all snaps that are included in Ubuntu do have to do.
And as they build on the exact same infrastructure as Ubuntu's .deb,
this is really no different from deb packages.

> - you cannot own your snap store and stay far away from USA (just in case...)

Staying away from the USA, sure you can. Canonical is primarily a US
company, the snap store and all Ubuntu core infrastructure is all
hosted in the UK :)
Canonical only operates some build machines and CDN nodes in the US.

The part about running your own snap store is definitely correct and
the snap store being effectively a walled garden is one of the main
issues I have with it.
There was a community project aimed at running an alternative store
some time ago, but I don't think that really went anywhere.

> For these reasons snap IS NOT DESIGN for Server critical use, but for desktops.

It was designed for IoT, extended for server stuff and then made to do
desktop stuff too. From a technical standpoint, it definitely sucks
the most at desktop stuff, where Flatpack tends to do far better.
The lack of initial focus on offline/airgaped system has definitely
been a problem, but it's a problem that has been worked on and does
have solutions available.



The real issues of snaps are much more centered around the trust model
which relies on a central store, curated and managed by Canonical.
The rationale for that on the Ubuntu side is that you already have to
trust Canonical anyway as whether through snaps or debs, the reality
is that they have root on your system if they want to.

It becomes a bit more problematic when used on other distributions. In
general the central store model does have some benefits, like
enforcing the same security review and policies across all snaps,
making things more discoverable, ...
That's why on the Flatpak side, flathub is so popular. The reality is
that users don't like having to hunt for repositories and have to
individually review them and trust them.
But not offering the option at all and relying on a closed source
store is definitely problematic.