On Fri, Sep 30, 2016 at 9:35 AM, Jan Pazdziora <jpazdziora(a)redhat.com> wrote:
On Fri, Sep 30, 2016 at 03:15:59PM +0200, Miroslav Suchý wrote:
> I am investigating
> and honestly I'm not sure what is the right solution.
> Right now we use unshare() for CLONE_NEWNS, CLONE_NEWUTS, CLONE_NEWIPC.
> I can detect if mock is running inside of container and then skip those unshare.
> But... What if I am running there some application *and* mock. In the same container.
That can be risky. However we can
> just document it and let the user shoot into its own leg.
Is there some example of application that might happen to run next to
mock? Running multiple applications in container is typically not
trivial, so user might make an extra effort to achieve that setup.
Can't just just check that you are pid 1 in the container and be happy
with that, if you want some safeguards?
The main case I could see wanting to run mock inside of Docker is for
CI systems. One of the more popular ones is Travis CI, and the only
way to get a decent environment to run mock in is with a Docker
container. So I would expect mock to be run alongside other things in
a CI context.
Likewise, I see this being quite valuable for people like myself using
GitLab CI for continually testing specs against multiple
distributions. I can set the CI environment to pull "fedora:latest",
but I want to run mock builds against multiple targets (Fedora, EPEL,
Mageia, etc.) and I'd like to verify it builds successfully in all of
those cases. Docker runners are all I have in GitLab CI on GitLab.com
So I would love to see this work!
真実はいつも一つ！/ Always, there's only one truth!