run: add support for swappable engines

[cgonyeo]

This commit revamps lib/run.go to rely on external binaries to perform
the actual execution of the desired command. Each external binary, or
engine, is expected to either exist on the PATH or in the same directory
as the acbuild binary, and must be named as acbuild-$ENGINENAME. The
default (and currently only) engine is systemd-nspawn.

When the engine is started a JSON message detailing what it is to run
and with what environment variables is written into it on stdin. The
package github.com/appc/acbuild/engine has been added to define the
schema for this (and also holds some helper utilities for engines).

Almost fixes #13.
Kind of a workaround for #162.

[cgonyeo]

I'd also like to use this opportunity to write some tests for run, and I'd like to make that part of this PR. So don't merge this until that's done, but putting this up for review until I finish that.

[cgonyeo]

Also as soon as this gets merged I'll add a chroot-only engine (guess I'll call it fly?) and explore adding a runc engine.

[cgonyeo]

pre-test review ping?

[jonboulle]

I don't really understand the motivation for introducing a new command-line API for this - it seems like an unnecessary layer of indirection - are you anticipating that it's too difficult for people to upstream engine implementations? I can't imagine we'd see more than a handful developed?

[cgonyeo]

I wanted to keep it easy for others to add engines, although if you think this is too much overhead I could just make it an interface that the engine author needs to implement.

On Mar 17, 2016, at 10:31, Jonathan Boulle [email protected] wrote:

I don't really understand the motivation for introducing a new command-line API for this - it seems like another layer of indirection - are you anticipating that it's too difficult for people to upstream engine implementations? I can't imagine we'd see more than a handful developed?

―
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

[cgonyeo]

I just changed this to have engines be a golang interface. This made some things in lib/run.go simpler.

[jonboulle]

Could inline a link to the engine section here.

[jonboulle]

Thanks, I think we should go with this interface route for now and then later if it makes sense we can explore the exec one

[cgonyeo]

Fixed the issues you found, updated the comment on lib/run.go, and added two tests for acbuild run.

[jonboulle]

Waiting on travis fix...

[cgonyeo]

Looks like the OS travis uses doesn't have systemd. I've modified TestRun so it gets skipped if ENABLE_SYSTEMD_TESTS isn't set. The test passes on my laptop, and when I implement other engines I can add in tests for those that'll run on travis.

[cgonyeo]

Travis is fixed. Last call for nits.

[jonboulle]

Docstring would be nice.

[jonboulle]

Two nits. LGTM.