[Podman] Re: podman on FreeBSD

Hi Valentin, I'm trying to come up with a few ground rules for this work and I'm suggesting these: - Keep code duplication to a minimum, factoring out platform-specific functions as needed ideally without reducing readability. - Take the project one file at a time to keep the pace manageable. Where a file with _linux suffix will be substantially shared with freebsd, first move the file from foo_linux.go to foo_common.go and in separate commits in the same PR, apply a minimum set of refactors to support the port. - At least until the main branch contains a working freebsd port, do not add freebsd to the cross-build smoke test - any build breaks I will handle after the fact. - Once basic functionality is present in the main branch, prioritise enabling at least a subset of the unit test suite. If possible, enable these in CI as a non-blocking signal - I'm aware this would add cost to the CI infrastructure and this needs to be considered before changing CI. In the short term, I have a small handful of PRs to add stubs to the tree which allow a non-functional freebsd build after which I would like to start working through libpod as described above, probably starting with oci_conmon_*.go.

Doug. On Wed, 10 Aug 2022 at 10:38, Doug Rabson <dfr(a)rabson.org&gt; wrote: > > > On Wed, 10 Aug 2022 at 09:19, Valentin Rothberg <vrothberg(a)redhat.com&gt; > wrote: > >> Thanks for reaching out, Doug! And thanks for your great work. >> > > Thanks for all your help getting this far! While working on buildah and > its supporting modules, I have been particularly grateful for the > thoughtful and detailed responses to my many PRs. > > >> >> On Tue, Aug 9, 2022 at 5:31 PM Doug Rabson <dfr(a)rabson.org&gt; wrote: >> >>> Over the last few months, I have been working on porting the >>> github.com/containers tool stack to FreeBSD, using the FreeBSD jail >>> subsystem for isolation. This builds on Samuel Karp's earlier work on runj, >>> which is a jail-based OCI runtime. >>> >>> Since buildah v1.27.0 contains working FreeBSD support for building >>> container images and it looks like this will be vendored into podman quite >>> soon, I would like to get the much larger set of changes for podman on >>> FreeBSD into review somehow. >>> >>> The complete set of FreeBSD changes is much too large for a single PR, >>> so I'm going to try to take this one file at a time. My plan is >>> approximately: >>> >>> 1. Add enough stubs to libpod to make it compile on FreeBSD >>> (without working at all) >>> 2. Pick a file from libpod/*_freebsd.go, ideally with the smallest >>> set of cross dependencies and make a PR which adds the freebsd file and in >>> a small stack of commits, factors out as much as possible of the shared >>> code between linux and freebsd. >>> 3. Work through review as normal until the PR can be merged. >>> 4. Go to step 2 unless I'm done. >>> >>> Does this seem reasonable? It's going to take a while - my working >>> branch has 21 freebsd files with varying degrees of complexity. >>> >> >> I would love to see Podman run on FreeBSD. But there are a number of >> issues I want to discuss beforehand: >> >> - *Who owns and maintains the FreeBSD code?* All current Podman >> maintainers are Linux people and I don't think there are free cycles to dig >> into FreeBSD. If it's only a single person maintaining the FreeBSD code it >> could be a threat to sustainability. Code must be maintained and evolved. >> Bugs need to be fixed. Same applies to CI systems and tests. >> >> Right now, it's just me working on this as a 'full time volunteer' which > is more efficient for the first pass zero-to-one phase (IMO). Having good > support for industry-standard container tools is important for the FreeBSD > project as a whole and is supported by the FreeBSD Foundation - I have > copied Ed Mast from the Foundation into this thread and he may be able to > comment on that. Personally, I believe that recruiting a little extra > support from the FreeBSD community will be possible if we can reach the > point where podman runs on FreeBSD. > > >> >> - Related to the point above: *How can we prevent the FreeBSD >> support from blocking Linux development?* There is a risk that >> changes (e.g., new features) to Linux containers may require changes to the >> FreeBSD code. I want to keep that to an absolute minimum, so we probably >> need to add abstractions in the form of interfaces at some places. >> >> This is a really important point. My experience so far working on a > prototype podman-on-freebsd has shown me that many of these abstractions > are already in place. In some places there are abstraction leakages but in > general, the code is already quite portable. Large parts of the code, even > code which currently is marked as Linux-only, worked unchanged on FreeBSD. > While working on adding run support to buildah, I was able to limit the > amount of FreeBSD-specific code to just 550 lines of code with more than > 1800 lines shared between the two platforms. This isn't necessarily a good > predictor for future work but it's encouraging (IMO). > > I absolutely do not want to impede Linux development. I want to do > anything I can to prevent that, through participating in code review, > consulting on differences in the platforms and fixing any breakage after > the fact to free up the Linux workflow. > > > >> >> - *How can we test? *I have no experience in FreeBSD but assume >> there is a way to run VMs with it and plug them into CI. Many tests won't >> run on FreeBSD, so we may need a simplified FreeBSD-specified testsuite. >> >> None of the points above must necessarily be blockers but I want to have >> a common understanding and set expectations (e.g., the FreeBSD support >> could very well be marked experimental). I am mostly afraid that it could >> be a constant burden on Linux development and hence be expensive for the >> entire project. >> > > Unit testing is also an extremely important factor. FreeBSD VMs are > supported by Cirrus CI and I want to get at least some of the test suite > functioning. At first glance, I think that some of the tests in > podman/test/system will work unmodified if I can supply a suitable test > image but I haven't actually tried this. > > Doug. > > > >> >> Kind regards, >> Valentin >> >> >>> Doug. >>> >>> _______________________________________________ >>> Podman mailing list -- podman(a)lists.podman.io >>> To unsubscribe send an email to podman-leave(a)lists.podman.io >>> >>