Muayyad & Neal,
That makes perfect sense. Thank you for the feedback. It might sound
crazy but I am keeping a list of every use case I can find and tracking our
progress with podman.
All of these use cases make sense (and I plan on tracking them in my list
when I get back to a computer). If I were to surmise, it sounds like many
people need some time to migrate certain use cases which have Docker
specific requirements. Hence, having the option of moby-engine around would
make that more convenient.
Sounds like there are two short term goals:
1. Update podman in CentOS. I have to dig into this to see if it is
tracking g the version in RHEL properly.
2. Add moby-engine to CentOS. This one might be interesting for for the
same reason, but admittedly it would be hard for me to push to dedicate Red
Hat people's time to package it. We would love a volunteer ;-)
So much work and so little time. I wish I could just knock out all of these
use cases out on a weekend, but a 19 month old has put a dent in my free
time :-)
Best Regards
Scott M
On Mon, May 6, 2019, 2:17 AM Neal Gompa <ngomp...@gmail.com> wrote:
> On Sun, May 5, 2019 at 6:39 PM Muayyad AlSadi <als...@gmail.com> wrote:
> >
> > > Is there some particular reason why you still want/need the Moby
> Engine package?
> >
> > no, I just want to have that option (even if in a non default repo) for
> convenient and easy migration and switch between old scripts/ansible
> playbooks, new fedora ...etc..
> >
> >
>
> At least for me, the main reason for moby-engine is that the GitLab CI
> Runner requires it. No one has contributed a port of the container
> runner executor to use Podman, so it requires Docker. It uses the
> Docker Engine API, so it can't be trivially replaced by the
> "podman-docker" package either.
>
> Without the enhancements to the Docker package though (that is,
> vanilla moby-engine), GitLab CI can't use RHEL environments without
> some manual work in the middle. :(
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
