Would you consider maintaining official packages on Fedora?

[pemensik]

Hi,

I have checked your COPR repository and it seems quite good and maintained with great care. Some of your packages are not yet officially packaged on Fedora. Could you please consider adding missing packages to Fedora Review process? It seems to me they would pass fine and you are already a packager.

I miss those packages you have already prepared:

• distrobuilder
• raft
• rubygem-ruby-lxc
• dqlite

Since you have already spent nontrivial effort to make and maintain them, could you maintain them in Fedora directly, please? Is there anything I can help you with making them official? I guess you could ask co-maintainer rights on the rest of packages also. Is there specific reason why you keep them updated here, but not in official repositories?

[ganto]

I already answered this question multiple times also see ganto/copr-lxd#6 and ganto/copr-lxc3#14. A while ago I also tried to reach out to the Fedora maintainer of the LXC package and offered my assistance but never got a reply. Since it was not too much effort I just continued doing my thing. Some things changed since then so'll quickly give you and everyone else interested in this topic my view on this:

• The raft and dqlite packages that you mentioned are low maintenance and I'll start a Fedora review process for those. I can totally do that. They became better maintained an released upstream in the last few months so that they are not only helper libraries for LXD (or even embedded) any more but individual projects.
• Distrobuilder unfortunately still doesn't have a proper release process. I personally never used it but it was simple enough to package so I added it to my COPR repository. If added to Fedora it would probably need some downstream release management to make it useful for potential users.
• The ruby-lxc bindings are unmaintained since a few years and the upstream code is not compatible with LXC 4.x (ruby-lxc broken by liblxc 4.0.4: undefined symbol: lxc_config_parse_arch lxc/ruby-lxc#45). I personally don't use Ruby and I just packaged it, because I was interested in how to write a spec file for a Ruby gem. Since there are not many voices in this Github repo that complain I don't think there are many users of this gem any more.

Now LXD itself is a real beast to properly integrate into Fedora. I currently see the following issues that needs work:

• LXD/LXD-client/LXD-agent (being mainly Ubuntu driven) are not built with the SELinux security model in mind but AppArmor. There was a short time a few years ago, where it worked with an "Enforcing" SELinux policy on the host, but at least since they added VM support it can only run on "permissive" hosts. The VMs being setup via LXD even run with SELinux completely disabled. From my point of view this requires a bit of work at least on the involved SELinux policies and probably also on LXD itself to make this work with enforcing. A quick search didn't reveal any hard requirement that an official Fedora package must be SELinux compatible but I personally expect that from an official package and would want to provide that for my packages.
• The VM support is tightly knit to the QEMU features available in Ubuntu. I think at the moment it should be possible to create a VM also on Fedora but I rarely test this especially not with all the features.
• The upstream release process is very much adjusted to the upstream snap distribution format. The tagged releases are more of release candidate quality. Subsequent critical bug fixes are then not released separately any more so a stable code state can only be found somewhere in release tag + hand picked patches. Because I don't use most of the LXD features I don't really invest much time in reviewing the patches and/or test for regressions but let users report if upstream (or Fedora) has broken something for them (e.g. LXD 3.20 Upgrade Containers Stopped Working copr-lxc3#21, lxcfs not starting since 4.0.4 #3, fedora34 post kernel 5.12.8-300 unable to enter running container #16). I don't really see how this release model fits into the Fedora release model. I guess you would be stuck with a LXD version within a Fedora release and maintain a LXD release much longer than it is supported upstream or risk that each LXD upgrade results in some weird breakage because there is no proper testing of the new releases on Fedora.
• I personally use LXD on Fedora the longer the less. My main job is now Kubernetes related and I find less and less opportunities and use cases to invest my time into LXD (on Fedora). E.g. I couldn't successfully build LXD >=4.16 on any of the current Fedora releases, it would just fail without obvious error message. After investing a full weekend without success, I'm currently kind of fed up. I would be willing to co-maintain the LXD package with 1-2 other people but not alone. My main OS always was and still is Gentoo where I also spend some time packaging software that I use much more often and I actually "only" use Fedora on some sandbox machines to practice for my former job as RHEL engineer. So you hopefully understand that I shy of the commitment to be the official Fedora maintainer of such a complex package.

I kindly accept patches so if people would like to support me in this effort that would be great.

[ganto]

Created Fedora package review requests:

• Bug 2017459 - Review Request: raft - C implementation of the Raft consensus protocol
• Bug 2017476 - Review Request: dqlite - Embeddable, replicated and fault tolerant SQL engine

If you're a Fedora package reviewer please have a look.

[pemensik]

Reviewed above reviews, no important issues found in them. I think *-static subpackage is not needed in Fedora and should not be provided, unless specific use-case for it exists.

My interest in lxc container relates to support of lxc containers in my Turris MOX router, which has built-in support for running lxc containers. It does not support lxd. Given difficulties you have described mxd would be difficult to run correctly. Could simpler packages be pushed to Fedora and lxd left to later time?

• distrobuilder were released in new version few days ago. I wanted to propose an update, but you have updated it yourself in the mean time. Not sure how much it is useful without proper template, but could you please make also distrobuilder review? It should be relative simple review.
• could you make review also for umoci package? I tried to follow lxc from docker article and used this command:
  lxc-create test-fedora-oci -t oci -- --url docker://registry.fedoraproject.org/fedora
  • It requires packages skopeo umoci, the latter is provided in your another repository.

As for LXD, I think it could be pushed to review also. If you state known issues in spec and/or in README.Fedora, I think it is still better than nothing. I admit proper enforcing SELinux support would be desired, but I guess lxd is something between libvirt and podman. It might be able to reuse some SELinux contexts of libvirtd maybe, not sure.

I think Fedora packages do not have to follow the same quality as RHEL packages should. It is more best-effort community distribution. If you have packages with issues, well, fedora-devel list can be asked for help. But no-one would order you to fix them, if it needs more work. I think having them as official packages would increase likehood of pull requests from people understanding SELinux much better than me. I think it should have selinux subpackage with policy enabling contexts for containers. But that can be added later as an improvement.

[ganto]

distrobuilder were released in new version few days ago. I wanted to propose an update, but you have updated it yourself in the mean time.

Ya, I saw that they made a new release so I quickly bumped the version in the spec file.

Could simpler packages be pushed to Fedora and lxd left to later time?

Ya, that's what I did with raft and dqlite but I still need an approval from Fedora legal because they use LGPLv3 with an exception clause. If I get LXD properly build on Fedora again one day, I might submit it maybe too... Let's see how it goes.

Regarding distrobuilder and umoci: Since you seem to use these tools regularly why don't you take over maintainership for those (I could be a co-maintainer if you wish)?

• umoci should be nearly no work at all. They have a release maybe once a year.
• distrobuilder might be a bit more effort depending on how much time you want to spend. When following their PRs and issues I feel it's still quite a laborious approach to keep this working for all different distributions. But it was no different with the old templates. Still I personally preferred the "old" way to create containers with the shell script templates that's why I also still package those. But also not sure how well they still work nowadays. I just felt they were more approachable.

I don't use both of these tools myself (only tried them once when they were new to me a few years ago) and I'm not attached at all to those spec files. You can take my spec files and submit them so that they are good for something at least. 😃

[mrmateo]

I really appreciate the work you have been doing to keep this going @ganto -- I use it every day for my dev workflow. I don't have much to add to the conversation as I am not too familiar with the packaging process but LXD does release an LTS version (currently based on 4.0) that is supported through 2025 and is limited to only bugfixes and very minor improvements. I think your concern of there being breaking changes in LXD versions is a valid one so maybe having only the LTS version in Fedora might be easier to maintain (i.e. hopefully nothing breaking b/w versions). Probably some sort of balance there though between stability/maintenance time and having the new features and functionality from new LXD versions.

[ganto]

There is some work in progress to finally bring Incus to Fedora. See RHBZ 2260492.