[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lxc-users
Subject:    Re: [lxc-users] LXD is no longer part of the Linux Containers project
From:       Stéphane_Graber <stgraber () ubuntu ! com>
Date:       2023-07-17 3:54:52
Message-ID: CA+enf=tWcTO5421-RpBpefTb+wDX9fA2LTfjMPnkuRda-nEf8g () mail ! gmail ! com
[Download RAW message or body]

On Sun, Jul 16, 2023 at 3:55 AM Nicolas FOURNIL
<nicolas.fournil@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.

> That's why I go far away from Ubuntu now (and more : security updates... for \
> subscribers !) 
> Le mer. 12 juil. 2023 à 03:02, Stéphane Graber <stgraber@ubuntu.com> a écrit :
> > 
> > On Wed, Jul 5, 2023 at 3:18 AM Narcis Garcia <debianlists@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.
> > 
> > > 
> > > 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:
> > > > 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
> > > > 
> > > 
> > > --
> > > 
> > > 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.
> > > 
> > > --
> > > 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+unsubscribe@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.
> > > 
> > 
> > --
> > 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+unsubscribe@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%3DtwkGtYKhAN5qMjtBCViPbU1LSOir4naUQxG6o%2BHhfzZA%40mail.gmail.com.
> > 

-- 
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+unsubscribe@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%3DtWcTO5421-RpBpefTb%2BwDX9fA2LTfjMPnkuRda-nEf8g%40mail.gmail.com.



[prev in list] [next in list] [prev in thread] [next in thread]