Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Mathias Gibbens <gibmat@debian.org> writes:
> Control: reassign -1 wnpp
> Control: retitle -1 ITP: Incus -- Powerful system container and virtual machine manager
> Control: severity -1 wishlist
> Control: block -1 by 1052536 1001989
>
> I'm converting this bug to an ITP, as there's clearly sufficient
> interest in the packaging of Incus. Plus, it will help track any
> dependencies that need to be packaged/updated for Debian.
+1, thanks.
> On Tue, 2023-09-19 at 08:44 +0100, Free Ekanayaka wrote:
>> The dependencies should be pretty much the same as LXD 5.16, except for
>> cowsql, and for a few dependencies that actually got dropped wrt LXD. So
>> that part should be relatively straightforward if you have already done
>> some work for LXD 5.16.
>
> There are two dependencies still in progress that are needed to
> properly build the latest feature release of LXD in Debian: golang-
> github-grafana-dskit (ITP#1001989; it has one dependency [golang-
> github-uber-jaeger-client-go] currently in NEW before I can package it)
> and updating golang-github-checkpoint-restore-go-criu to v6 (currently
> on v5, with a patch to undo its use in the current LXD packaging).
It seems that v6 of golang-github-checkpoint-restore-go-criu is in
experimental:
https://packages.debian.org/experimental/golang-github-checkpoint-restore-go-criu-dev
Not sure if there are blockers for it to move to unstable (maybe we'd
need to drop the patch currently applied to the LXD package?).
>> We were thinking more or less the same, but with a difference: what
>> about uploading to Debian only the LTS updates of LXD for now (that
>> means the 5.0.x releases) and start uploading the Incus development
>> releases (once the first is out)?
>
> That seems reasonable to me. I know people occasionally ask for the
> latest version of LXD, which someday I might upload to experimental on
> a "best effort" basis, but the main packaging for LXD will follow the
> LTS releases. Prior to Incus' 1.0 LTS release, I think it would be
> great to upload development releases to facilitate testing by
> interested users.
Yes, agrred. Incus 0.1 has now been released, and I've updated the salsa
repository accordingly.
I've also switched the packaging branch from debian/experimental to
debian/unstable, as actually I don't see a reason for not uploading to
unstable at this stage.
Once Incus 1.0 LTS is out we could opt for uploading only LTS updates to
unstable and development releases to experimental.
>> Once trixie gets released it would contain the latest LXD 5.0.x release
>> (which upstream supports until June 2027), and the latest Incus LTS
>> release. Bookworm users can upgrade to trixie and then migrate their
>> deployments to Incus using the lxd-to-incus tool, if they wish to.
>
> Just a minor note -- if LXD keeps its established release schedule,
> I'm expecting LXD 6.0.x to ship in trixie.
Yes, although I would personally keep Debian's LXD at version 5.0.x for
trixie and point users to the lxd-to-incus migration tool, to migrate
from LXD 5.0.x to Incus 1.0.x, which should be be a superset of LXD
6.0.x.
That's of course just might take, I understand that there might be
interest from other DDs/users (e.g. you) to update the Debian's package
to LXD 6.0.x.
> We will definitely want test the transition path and ensure there's
> good documentation in place for the trixie release.
+1
>> As for now cowsql's raft is compatible with dqlite's raft, and I plan to
>> maintain that compatibility, at least as far as the LXD+dqlite stack is
>> concerned (which is what matters for Debian).
>>
>> What I'd propose would be to change the upstream of the libraft package
>> in Debian from canonical/raft to cowsql/raft, and I could (co-?)maintain
>> the libraft package as well as the dqlite one, making sure they work
>> together (that might help Laszlo too, taking some work off his plate, I
>> can reach out to him and ask).
>
> Currently in unstable there are only three rdeps of src:raft: dqlite,
> golang-github-canonical-go-dqlite, and lxd. So it would certainly be
> doable to switch the upstream of src:raft -- if Laszlo is open to doing
> so, it should be a pretty easy transition. Probably the trickiest thing
> would be the versions: I'd like to avoid a package epoch bump if
> possible, and we'd also have to consider the .so versioning.
Why do think an epoch is needed? I believe it can be done without
epochs. Anyway, if the idea gets consenus I'll coordinate with Laszlo
about that.
>> It's still very early on and it's not working yet (I've mostly rebranded
>> the debian/ directory of the lxd Debian source package), but it's a
>> start, so perhaps we might already have something kind of working by the
>> time the first Incus release is out.
>
> At least initially, I'd like to keep the packaging for LXD and Incus
> as similar as possible. I know over time things will diverge, but for
> now I think keeping the delta between packages small will be
> beneficial.
Yes, agreed. At the moment the incus packaging repo is most a rebranding
of the lxd one.
Free
Reply to: