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. Doug.
On 8/9/22 11:29, Doug Rabson wrote:
Over the last few months, I have been working on porting the github.com/containers <http://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.
Doug.
_______________________________________________ Podman mailing list --podman@lists.podman.io To unsubscribe send an email topodman-leave@lists.podman.io
That sounds good to me.
Thanks for reaching out, Doug! And thanks for your great work. On Tue, Aug 9, 2022 at 5:31 PM Doug Rabson <dfr@rabson.org> 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. - 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. - *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. Kind regards, Valentin
Doug.
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
On Wed, 10 Aug 2022 at 09:19, Valentin Rothberg <vrothberg@redhat.com> 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@rabson.org> 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@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
I don't want to interfere with the discussion and decision-making process. I just want to express my excitement and say that enabling FreeBSD support for Podman sounds to be super interesting. I can't dedicate much of my community contributor time to it right now, but I would really like and try to participate, making at least some small contributions to the subject in the future. Hopefully, more people could be interested if you decide to move forward and later after you do some community announcements. Regards, Jakub On Wed, Aug 10, 2022 at 11:39 AM Doug Rabson <dfr@rabson.org> wrote:
On Wed, 10 Aug 2022 at 09:19, Valentin Rothberg <vrothberg@redhat.com> 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@rabson.org> 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@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
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@rabson.org> wrote:
On Wed, 10 Aug 2022 at 09:19, Valentin Rothberg <vrothberg@redhat.com> 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@rabson.org> 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@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
I would focus on using a container to test building of podman under GHA, at least until we can setup some real BDS runners which can also run the tests. Still, having the container build pipeline is an essential steps towards making BSD support real, and more important, preventing other changes from being introduced. Cheers Sorin On 14 Aug 2022 at 13:21:33, Doug Rabson <dfr@rabson.org> wrote:
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@rabson.org> wrote:
On Wed, 10 Aug 2022 at 09:19, Valentin Rothberg <vrothberg@redhat.com> 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@rabson.org> 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@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
_______________________________________________
Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
Hi Doug, On Sun 14 Aug 2022 at 14:22, Doug Rabson <dfr@rabson.org> wrote:
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.
This sounds good to me, thanks! Kind regards, Valentin
Doug.
On Wed, 10 Aug 2022 at 10:38, Doug Rabson <dfr@rabson.org> wrote:
On Wed, 10 Aug 2022 at 09:19, Valentin Rothberg <vrothberg@redhat.com> 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@rabson.org> 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@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
participants (5)
-
Daniel Walsh -
Doug Rabson -
Jakub Guzik -
Sorin Sbarnea -
Valentin Rothberg