Hey Mathias, Mathias Gibbens <gib...@debian.org> writes:
> Hi Free, > > On Fri, 2023-09-15 at 13:22 +0100, Free Ekanayaka wrote: >> Hello! >> >> as you probably know, the initial fork from: >> >> https://github.com/cyphar/incus/ >> >> has now been moved under the LXC project: >> >> https://github.com/lxc/incus, >> >> and has definitely gained traction since the initial announcement, >> getting support both from the community and from LXD developers that >> have now moved to incus (myself included). > > Yes, I've been keeping an eye on Incus' development and am glad to > see it's off to a good start! Indeed! >> I wanted to wait for the first official incus release before reaching >> out to Debian fellows, but since I noticed that you might be working >> on updating the LXD package I thought it be good to get in contact. > > I was also planning to wait for the first official release before > diving into packaging for Debian, as I know (at least at first) there > was a ton of churn in dependencies and the naming of binaries. But it's > never too early to start the conversation. :) Right, agreed. As far as the first release is concerned I think it's now approaching, and it should happen within the next few weeks. The re-naming of the binaries has been completed, but there are still a few sub-commands in those binaries that are being renamed. 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. 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. Stéphane Graber can provide more information here (or amend anything I said). > As I've thought over things more, I think the ideal path forward > would be to have both LXD and Incus available in Debian. That will give > users the most freedom to choose what they want to install on their > systems, and if down the road either of the projects winds down we can > help them migrate to the other project as needed. 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 would support current Debian LXD users, give folks a chance to try out Incus, and simplify a bit the packaging situation (see below for details). There is a lxd-to-incus tool in Incus that Debian users will be able to use to migrate their LXD deployments to Incus: assuming that you have both lxd and incus installed, typing "sudo lxd-to-incus" should just work and get everything migrated from lxd to incus. 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. Since the release of Trixie is still relatively far away, we could always revisit this approach and start uploading new development (or LTS) releases of LXD too. >> As Debian developer myself, incus maintainer and original author of >> dqlite/libraft (which have now been forked too into the new "cowsql" >> project https://github.com/cowsql, used by incus), I'd of course love >> to see Debian switching to incus and cowsql, and in that case I'd >> like to help out with packaging and maintainership. > > Of course! The more the merrier! LXD is currently team-maintained > under the Go Team, although in practice I'm the only one performing > uploads. I would envision a similar setup for the packaging of Incus, > and would welcome your help with it. I'm already part of the Go packaging team, I'll start giving a look at the repositories then, and perhaps start creating the Incus one. > I haven't seen any RFP/ITPs for cowsql, go-cowsql, or the fork of > raft; are you planning to work on getting those packaged for Debian? Yes, I can do that, I was mainly waiting to have this conversation to have a plan about how to do it (see below as well). > If not, eventually I'll get around to them. :) The only heartburn I have > is with the fork of raft -- from a quick inspection, it looks like the > package has the same name (both for the package and shared library) as > Canonical's version of raft which is already packaged. Would it be too > much work to change the name of the fork, so it would be trivial to > have co-installed versions of raft? So, first of all, I was reluctant to fork and I tried for quite some time to collaborate with Canonical on dqlite, but I felt that upper management was not interested in having a "community" (however small) around the project, with which to share plans and decisions in full openness. For cowsql I was of course forced to change the name, since although I'm the author of dqlite (I basically wrote it all), I unfortunately could not claim that trademark in case of disputes. For raft, that's not a trademark of Canonical, it's just the name of an algorithm, and virtually any Raft implementation library out there is called just "raft". 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). In case there's consenus about sticking to the LXD 5.0.x series for trixie, it would be very easy to have cowsql's libraft support both dqlite and cowsql. However, sticking to LXD 5.0.x is not really a blocker for having a single libraft, it just requires a bit more care from my side. Note that (go-)dqlite/raft have been stable for a number of years now, as far as LXD is concerned, and I'm very familiar with that stack, since I'm the one that wrote it (including the LXD clustering part). >> Within the incus team we have discussed possible Debian-specific >> migration strategies and we'd have ideas about how to handle it, so >> users experience the least possible disruption. > > I'd certainly like to see that. Debian is tracking the LTS releases, > and it would be a good release goal for trixie to have a migration path > from LXC -> Incus for users if they wish. Yes, that'd be our idea too, as described above. The lxd-to-incus tool is already functional, module minor tweaks that we'd need for Debian-specific deployments, but we'll get them in place soon. That'd be another reason for having Debian stick to LXD 5.0.x: it'd make life a easier for the Incus team, since we can have a single and stable pre-fork basis from which we know the tool migrates data from. > >> I'd like to know what are your feelings around these topics, and of >> course I understand if you prefer to just sit on the sidelines for >> now. > > Speaking strictly for myself, I'm planning to switch to Incus once it > hits a "1.0 LTS" sort of release. As such, I'll have a vested interest > in getting it into Debian. I'll be glad to collaborate with you or > anyone else who would like to work on the Debian packaging. Great, I'm on board! > And for the foreseeable future I'll also keep LXD up to date with its > LTS releases for those who choose to stay with it. Okay. For the reasons above, please also consider the option of sticking to the current LXD 5.0.x LTS, at least for now. I surely understand if that's absolutely out of question for you though. Cheers, Free
