Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Incus 0.4 has been uploaded to NEW. Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
At the end of the weekend, I think packaging for Incus is at the point that we're ready for an upload to NEW once golang-github- canonical-lxd-dev clears. I have applied a patch to disable the loki logging integration for the time being and return an error if someone tries to configure it. Basic functionality seems to be working on my sid box: * Container creation/use/deletion * VM creation/use/deletion * lxd-to-incus for containers and VMs - Side note: I feel that currently lxd-to-incus is a bit aggressive in blindly renaming /var/lib/lxd/, /var/log/lxd/, and /var/cache/lxd/, as that breaks LXD if you try to re-start it after the migration and didn't auto-purge it at the end of lxd-to-incus. However, as I think the only time someone would run lxd-to-incus is in advance of removing LXD, I don't know if it's really too much of an issue to worry about or not... Untested are things like various storage backends, cluster mode, etc. I also went through and cleaned up the debian/ directory. If anyone else wants to play with the current packaging, I've pushed everything up to salsa. Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Mathias Gibbens writes: > Late last night I successfully built Incus as a Debian package for > the first time! ️ > > There are two blockers before we can perform the initial upload to > NEW: > > 1 -- Remaining build deps: > > * We're still waiting on bin:golang-github-canonical-lxd-dev to > make it through NEW. > > * golang-github-grafana-dskit-dev still needs to be packaged, but > Incus seems to only have a single use of that library in > internal/server/loki/loki.go. Last night I just patched out any > reference in loki.go to dskit/backoff so everything else could build. > Obviously not an ideal approach. However, do we want to consider > disabling loki support in Incus for the time being to facilitate > getting Incus into Debian? I'll keep working on packaging dskit and > eventually we can re-enable loki support once it's packaged. I think that's a very reasonable approach. Perfect is the enemy of good. > 2 -- Testing/QA: > > * General testing: Later today I'm planning to start testing Incus > on a sid machine. I'm sure this will turn up various things to > fix/tweak. Before uploading to NEW, at a minimum I'll want to make sure > containers and VMs work out-of-the-box. > > * LXD migration: Simple migrations from LXD to Incus should work. > > * QA: Go through the debian/ directory in the Incus packaging to > make sure it's all in good shape and is synced up with current LXD > packaging work. > > Excited to be close to the finish line on this! Thank you Mathias! I've been a bit on the sidelines the last few weeks, but I'm still around :)
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
On Sat, Jan 6, 2024 at 12:52 PM Mathias Gibbens wrote: > > Late last night I successfully built Incus as a Debian package for > the first time! ️ Nice! > There are two blockers before we can perform the initial upload to > NEW: > > 1 -- Remaining build deps: > > * We're still waiting on bin:golang-github-canonical-lxd-dev to > make it through NEW. > > * golang-github-grafana-dskit-dev still needs to be packaged, but > Incus seems to only have a single use of that library in > internal/server/loki/loki.go. Last night I just patched out any > reference in loki.go to dskit/backoff so everything else could build. > Obviously not an ideal approach. However, do we want to consider > disabling loki support in Incus for the time being to facilitate > getting Incus into Debian? I'll keep working on packaging dskit and > eventually we can re-enable loki support once it's packaged. I'm not terribly familiar with the LOKI integration but that particular dependency has been bothering me for a while given how much stuff it pulls in. I'd love to see it gone, but I'd have to figure out exactly what's needed and how easy it may be to re-implement. I wouldn't expect the LOKI log ingest protocol to be so complicated that it needs such a large dependency chain. > 2 -- Testing/QA: > > * General testing: Later today I'm planning to start testing Incus > on a sid machine. I'm sure this will turn up various things to > fix/tweak. Before uploading to NEW, at a minimum I'll want to make sure > containers and VMs work out-of-the-box. > > * LXD migration: Simple migrations from LXD to Incus should work. > > * QA: Go through the debian/ directory in the Incus packaging to > make sure it's all in good shape and is synced up with current LXD > packaging work. > > Excited to be close to the finish line on this! Yep, exciting times! > Mathias -- Stéphane
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Late last night I successfully built Incus as a Debian package for the first time! ️ There are two blockers before we can perform the initial upload to NEW: 1 -- Remaining build deps: * We're still waiting on bin:golang-github-canonical-lxd-dev to make it through NEW. * golang-github-grafana-dskit-dev still needs to be packaged, but Incus seems to only have a single use of that library in internal/server/loki/loki.go. Last night I just patched out any reference in loki.go to dskit/backoff so everything else could build. Obviously not an ideal approach. However, do we want to consider disabling loki support in Incus for the time being to facilitate getting Incus into Debian? I'll keep working on packaging dskit and eventually we can re-enable loki support once it's packaged. 2 -- Testing/QA: * General testing: Later today I'm planning to start testing Incus on a sid machine. I'm sure this will turn up various things to fix/tweak. Before uploading to NEW, at a minimum I'll want to make sure containers and VMs work out-of-the-box. * LXD migration: Simple migrations from LXD to Incus should work. * QA: Go through the debian/ directory in the Incus packaging to make sure it's all in good shape and is synced up with current LXD packaging work. Excited to be close to the finish line on this! Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Yeah, it's my current plan to keep providing image server access to Debian users until the trixie release or until Incus makes it to bookworm-backports whichever happens first. We don't really want to block access to users who don't have a good way out. So while the published plan is fast paced and sounds pretty strict, we fully expect to be making exceptions where they make sense and where a clear timeline is known (as is the case with the trixie release). Stéphane On Wed, Dec 27, 2023, 1:03 p.m. Free Ekanayaka wrote: > Free Ekanayaka writes: > > > Raphael Hertzog writes: > > > >> Hello, > >> > >> On Tue, 26 Dec 2023, Mathias Gibbens wrote: > >>> On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote: > >>> > I would really like to see incus in unstable/testing and even in > >>> > bookworm-backports at some point. > >>> > >>> Given the large number of new/updated dependencies for Incus, it > >>> would be a lot of work to properly prepare a release for bookworm- > >>> backports once Incus gets into unstable. Not saying that it couldn't be > >>> done, but I don't know if it would be worth the effort. If you would > >>> like to use Incus on bookworm right now, probably the best approach > >>> would be to install the package from Stéphane's repo: > >>> https://github.com/zabbly/incus. > >> > >> If we want to run debusine on a DSA-managed servers, we need to have > >> packages available on official Debian repositories, hence > >> bookworm-backports as installing packages from testing/unstable is out > of > >> question. :-| > > > > I agree with Mathias that having Incus in bookworm-backports requires > > quite a bit of work. It's probably doable (although we'll have to assess > > if that'd introduce tricky dependency conflicts), but perhaps having > > some more folks helping with it would make it more feasible. > > BTW, assuming that you don't need any "new" feature from later lxd/incus > releases, one option would be to have debusine conditionally use the lxd > package from bookworm when running on bookworm and incus when running on > trixie (or alternatively just use lxd on both and migrate later on down the > road). I think that would be much less work than backporting. > > The only problem would be that the image server run by LinuxContainers > is going to phase out support for LXD [0], so at some point bookworm's > lxd package will stop being able to pull images from there. > > One workaround would be to have Stéphane make an exception to the phase > out plan, and let bookworm's lxd keep working normally (at least until > trixie is released). I'm not sure how much he's willing to do that, but > I believe he's open to that possibility if other options (like > backporting incus) are not quite viable. > > [0] > https://discuss.linuxcontainers.org/t/important-notice-for-lxd-users-image-server/18479 >
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Free Ekanayaka writes: > Raphael Hertzog writes: > >> Hello, >> >> On Tue, 26 Dec 2023, Mathias Gibbens wrote: >>> On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote: >>> > I would really like to see incus in unstable/testing and even in >>> > bookworm-backports at some point. >>> >>> Given the large number of new/updated dependencies for Incus, it >>> would be a lot of work to properly prepare a release for bookworm- >>> backports once Incus gets into unstable. Not saying that it couldn't be >>> done, but I don't know if it would be worth the effort. If you would >>> like to use Incus on bookworm right now, probably the best approach >>> would be to install the package from Stéphane's repo: >>> https://github.com/zabbly/incus. >> >> If we want to run debusine on a DSA-managed servers, we need to have >> packages available on official Debian repositories, hence >> bookworm-backports as installing packages from testing/unstable is out of >> question. :-| > > I agree with Mathias that having Incus in bookworm-backports requires > quite a bit of work. It's probably doable (although we'll have to assess > if that'd introduce tricky dependency conflicts), but perhaps having > some more folks helping with it would make it more feasible. BTW, assuming that you don't need any "new" feature from later lxd/incus releases, one option would be to have debusine conditionally use the lxd package from bookworm when running on bookworm and incus when running on trixie (or alternatively just use lxd on both and migrate later on down the road). I think that would be much less work than backporting. The only problem would be that the image server run by LinuxContainers is going to phase out support for LXD [0], so at some point bookworm's lxd package will stop being able to pull images from there. One workaround would be to have Stéphane make an exception to the phase out plan, and let bookworm's lxd keep working normally (at least until trixie is released). I'm not sure how much he's willing to do that, but I believe he's open to that possibility if other options (like backporting incus) are not quite viable. [0] https://discuss.linuxcontainers.org/t/important-notice-for-lxd-users-image-server/18479
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Raphael Hertzog writes: > Hello, > > On Tue, 26 Dec 2023, Mathias Gibbens wrote: >> On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote: >> > I would really like to see incus in unstable/testing and even in >> > bookworm-backports at some point. >> >> Given the large number of new/updated dependencies for Incus, it >> would be a lot of work to properly prepare a release for bookworm- >> backports once Incus gets into unstable. Not saying that it couldn't be >> done, but I don't know if it would be worth the effort. If you would >> like to use Incus on bookworm right now, probably the best approach >> would be to install the package from Stéphane's repo: >> https://github.com/zabbly/incus. > > If we want to run debusine on a DSA-managed servers, we need to have > packages available on official Debian repositories, hence > bookworm-backports as installing packages from testing/unstable is out of > question. :-| I agree with Mathias that having Incus in bookworm-backports requires quite a bit of work. It's probably doable (although we'll have to assess if that'd introduce tricky dependency conflicts), but perhaps having some more folks helping with it would make it more feasible.
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Hello, On Tue, 26 Dec 2023, Mathias Gibbens wrote: > On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote: > > I would really like to see incus in unstable/testing and even in > > bookworm-backports at some point. > > Given the large number of new/updated dependencies for Incus, it > would be a lot of work to properly prepare a release for bookworm- > backports once Incus gets into unstable. Not saying that it couldn't be > done, but I don't know if it would be worth the effort. If you would > like to use Incus on bookworm right now, probably the best approach > would be to install the package from Stéphane's repo: > https://github.com/zabbly/incus. If we want to run debusine on a DSA-managed servers, we need to have packages available on official Debian repositories, hence bookworm-backports as installing packages from testing/unstable is out of question. :-| Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote: > I would really like to see incus in unstable/testing and even in > bookworm-backports at some point. Given the large number of new/updated dependencies for Incus, it would be a lot of work to properly prepare a release for bookworm- backports once Incus gets into unstable. Not saying that it couldn't be done, but I don't know if it would be worth the effort. If you would like to use Incus on bookworm right now, probably the best approach would be to install the package from Stéphane's repo: https://github.com/zabbly/incus. On Mon, 2023-12-25 at 12:30 +, Free Ekanayaka wrote: > Yes, Mathias and I are working on uploading Incus to unstable. You > can follow the progress here: > > https://wiki.debian.org/Incus > > we're definitely close-ish now, but there are still a few things to > do. Yesterday I pulled the 0.4 release into the salsa packaging repo for Incus and updated d/control to reflect the various build dependencies. I've also updated the wiki page to reflect the current list of remaining dependencies needed to be packaged/updated. Probably the biggest bit of work left is updating the existing dependencies for golang-github-grafana-dskit -- I've pushed some packaging updates to the various salsa repos, but actually uploading will require testing reverse build deps and possibly coordinating updates in affected packages. Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Hello Raphael, Raphael Hertzog writes: > Hello, > > On Sat, 21 Oct 2023, Free Ekanayaka wrote: >> raft 0.17.7-1 is now in unstable, and I've uploaded cowsql 1.15.3-1, >> which is waiting in the NEW queue. > > This one is available in unstable now. I would really like to see incus > in unstable/testing and even in bookworm-backports at some point. Yes, Mathias and I are working on uploading Incus to unstable. You can follow the progress here: https://wiki.debian.org/Incus we're definitely close-ish now, but there are still a few things to do. > We are considering to use LXD in the context of debusine[1] Very nice project, I didn't know about it, thanks. > but given the latest developments with Canonical, it would make sense > for us to start directly with incus. Yeah, I'd of course recommend that. Although if you really need to make progress now, using LXD and then migrating to Incus shouldn't be hard, both in terms of scripts/code and of existing deployments. YMMV. > I think it would make sense to upload current (non-LTS) versions in > unstable right ahead and then stick to the LTS version once they have > released it. That's the plan indeed. Free
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Hello, On Sat, 21 Oct 2023, Free Ekanayaka wrote: > raft 0.17.7-1 is now in unstable, and I've uploaded cowsql 1.15.3-1, > which is waiting in the NEW queue. This one is available in unstable now. I would really like to see incus in unstable/testing and even in bookworm-backports at some point. We are considering to use LXD in the context of debusine[1] but given the latest developments with Canonical, it would make sense for us to start directly with incus. I think it would make sense to upload current (non-LTS) versions in unstable right ahead and then stick to the LTS version once they have released it. Cheers, [1] https://freexian-team.pages.debian.net/debusine/ -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Hi guys, raft 0.17.7-1 is now in unstable, and I've uploaded cowsql 1.15.3-1, which is waiting in the NEW queue. Free
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Mathias Gibbens writes: > On Sun, 2023-10-08 at 12:19 +0100, Free Ekanayaka wrote: >> 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?). > > 31/35 of the rdeps of golang-github-checkpoint-restore-go-criu build > fine with v6.3.0 from experimental -- the big blocker is runc. Its most > recent release (1.1.9) still depends on v5, although in the upstream > main branch it's been switched to v6. Given that runc is a fundamental > container library, I'll want to confer with the Go Packaging Team on > how to move forward with this. > > (And LXD currently has a patch to revert the simple use of go-criu, > so when v6 lands in unstable that's a simple thing to remove.) It sounds good to me to use the patch for the Incus package as well, and remove it later on when the situation unblocks. >> Once Incus 1.0 LTS is out we could opt for uploading only LTS updates >> to unstable and development releases to experimental. > > That's the mental idea I've had for LXD as well, although I haven't > actually done that yet. One of the tricky things would be managing two > distinct upstream branches (upstream-lts and upstream-dev maybe?) and > then merging Debian-specific packaging changes from unstable <-> > experimental. Yeah, maybe something like that. > >> > 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 [my] 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. > > With my DD hat on, I don't want to artificially hold back the version > of LXD in trixie solely to make life easier for Incus -- especially if > there's a 6.0 LTS release out with plenty of time before freezes start. > Doing so would be a disservice to users wishing to run LXD and have the > latest LTS release available in trixie. Note that LXD's recommended installation way is via snapd, which should be available in Debian, so Debian users wishing to run 6.0 LTS would have that option, albeit not "native". That being said, I certainly understand your reasoning. > I know there will be a growing delta between LXD and Incus as time > goes on, but I would also suspect Incus will want to support migrations > from newer versions of LXD as best as it can. Yeah, I think so, I'm just not sure how much that will be practically feasible, so probably the answer is "it depends". I'll ask Stéphane too about this. I don't think there's any certainty here, but he should be able to provide an educated guess about whether Incus 1.0 might be able to support migrations from LXD 6.0. > >> > 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. > > Looks like you've picked an initial release version of 0.17.7, so I > guess that side-steps the epoch bump issue in Debian's packaging, but I > don't know about resetting the .so version back to zero. Yeah, there was a bit of a mess in the past with .so versions. It should have been kept to 0 all the way in the first place, and ABI compatibilty should have not been broken. >From now on, I'll make sure that the .so version stays at 0 and that all releases in the 0.x series are backward-compatible both in terms of API and ABI. In the long term I plan to eventually have a 1.x series too, which will likely break ABI compatibility, and require a .so version bump to 1, but that's relatively far in the future. > Is there anything in Policy about a "backwards" transition? I don't think there's any hard rule, or at least I didn't find anything specific about that in: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html > While there wouldn't be API compatibility, this would introduce two > different "libraft.so.0" files into the archive. (And a future ".so.1" > and ".so.2".) Maybe we could find another C library that changed its > upstream to see how they handled it? Mostly I just don't want to >
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
On Sun, 2023-10-08 at 12:19 +0100, Free Ekanayaka wrote: > 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?). 31/35 of the rdeps of golang-github-checkpoint-restore-go-criu build fine with v6.3.0 from experimental -- the big blocker is runc. Its most recent release (1.1.9) still depends on v5, although in the upstream main branch it's been switched to v6. Given that runc is a fundamental container library, I'll want to confer with the Go Packaging Team on how to move forward with this. (And LXD currently has a patch to revert the simple use of go-criu, so when v6 lands in unstable that's a simple thing to remove.) > 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. Fine by me -- for a brand new package there doesn't seem to be much reason to first target experimental, in my opinion. > Once Incus 1.0 LTS is out we could opt for uploading only LTS updates > to unstable and development releases to experimental. That's the mental idea I've had for LXD as well, although I haven't actually done that yet. One of the tricky things would be managing two distinct upstream branches (upstream-lts and upstream-dev maybe?) and then merging Debian-specific packaging changes from unstable <-> experimental. > > 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 [my] 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. With my DD hat on, I don't want to artificially hold back the version of LXD in trixie solely to make life easier for Incus -- especially if there's a 6.0 LTS release out with plenty of time before freezes start. Doing so would be a disservice to users wishing to run LXD and have the latest LTS release available in trixie. I know there will be a growing delta between LXD and Incus as time goes on, but I would also suspect Incus will want to support migrations from newer versions of LXD as best as it can. > > > 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. Looks like you've picked an initial release version of 0.17.7, so I guess that side-steps the epoch bump issue in Debian's packaging, but I don't know about resetting the .so version back to zero. Is there anything in Policy about a "backwards" transition? While there wouldn't be API compatibility, this would introduce two different "libraft.so.0" files into the archive. (And a future ".so.1" and ".so.2".) Maybe we could find another C library that changed its upstream to see how they handled it? Mostly I just don't want to accidentally cause a (subtle) mess somewhere down the road. This evening I created an initial wiki page as well, which at the moment is just tracking some of the remaining dependencies for Incus' packaging: https://wiki.debian.org/Incus. Mathias signature.asc Description: This is a digitally signed message part
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
Mathias Gibbens 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,
Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager
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. 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). > The idea is to have Incus follow a release scheme similar to LXD, with > LTS releases every 2 years or so, and "development" releases in > between. The first LTS release would probably come out early next year. That sounds great, and will fit nicely into the trixie development cycle! > 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. > 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. We will definitely want test the transition path and ensure there's good documentation in place for the trixie release. > 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. On Sun, 2023-09-24 at 15:54 +0100, Free Ekanayaka wrote: > I've created the Salsa repository for the incus Debian source package: > > https://salsa.debian.org/go-team/packages/incus +1 > > 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. > I've now filed an ITP for cowsql: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052536 Saw that, thanks! Mathias signature.asc Description: This is a digitally signed message part
