-
Notifications
You must be signed in to change notification settings - Fork 79
*: recipe for running acbuild in container #86
Comments
In a fedora 22 container:
Perhaps once alternate execution environments is implemented this will be possible, but it doesn't look like this is feasible with the current state of acbuild. |
@dgonyeo how about a container based on CoreOS or something to pick up a more modern systemd-nspawn? That check was removed a while ago: systemd/systemd@4f923a1 |
I made a container out of
Any clue what's going on here? I can't figure out why it would be a read-only file system. |
Weird. Can you narrow it down to an explicit systemd nspawn invocation case On Tue, Nov 3, 2015, 19:40 Derek Gonyeo [email protected] wrote:
|
Yup. The directory I'm pointing systemd-nspawn at here is the rootfs from quay.io/coreos/alpine-sh.
|
I just tried this in an ACI made out of gentoo's stage 3, and get a different, but similar output to when it was in the coreos ACI.
|
Any luck troubleshooting this further? perhaps ping upstream systemd? |
You might try invoking nspawn with --boot so it starts an init.
|
I really want this. Not sure how this'll be solved given the need for OverlayFS… Is it even possible to interact with kernel-level stuff like that in an ACE container? |
We should have acbuild packaged in an ACI and then be able to invoke it using any appc runtime, e.g. rkt. I expect this would just mount in the user's project/asset directly to a known location (
/data
or whatever) and then run the script they pass to it.For example with rkt this might look like:
Where "data" would be defined as a mountpoint in the
appc.io/acbuild
image.Then this would output the ACI in the same directory.
The text was updated successfully, but these errors were encountered: