lxc-start-ephemeral script does not support in-line programmatic commands to ephemeral containers

The original script created the ephemeral container, started it with lxc-start, then ssh'd to it.

I wonder if it would suffice to create the ephemeral container, then run the specified command in it with lxc-execute, rather than using lxc-start. That would mean the upstart jobs would not start however.

Would that suffice for your use case?

Yes, the way the ssh was assembled was a bit rough--running sed over the dhcp leases to find the ip address of the container name. In the solution I proposed on this bug, we were going to initially do the same within the command string. At least the hack would not be in lxc itself. Later we might be able to make it a bit more pleasant by using avahi in the container and sshing to [container name].local.

My best understanding of lxc-execute is that it won't be sufficient. We need a number of system services to run Launchpad tests, especially Apache and Postgres. However, I'm happy to be educated and shown to be wrong--perhaps we could write a custom script that would start what we needed and then do the actual job we want. The fact we have to use sudo with this solution (AIUI) is a bit of a problem too: we want automated processes to run this, and we really don't want to run them with root privileges, nor with a root password.

This version of lxc-start-ephemeral makes the following changes:

1. drops aufs (doesn't work on precise)
2. if COMMAND is specified, then, as in Robert's original version, the container executes the command and then is destroyed. If no COMMAND is specified, it waits until it is stopped (i.e. with lxc-stop)
3. cleans up on SIGINT etc

Thank you Serge. The switch from aufs looks good.

We're evaluating it now. We'll have feedback soon.

With the fix from bug 914169, the only basic change we need in this script is as follows:

121,122c121,122
< mkdir -p $LXC_DIR/rootfs/var/lib/dhcp3
< mkdir -p $LXC_DIR/rootfs/var/lib/dhcp
---
> sudo mkdir -p $LXC_DIR/rootfs/var/lib/dhcp3
> sudo mkdir -p $LXC_DIR/rootfs/var/lib/dhcp

We're also interested in making the ssh call more robust by retrying a few times if it fails. Sometimes the sshd has not yet started in the container, so this can give spurious errors. We gave an initial stab at this but do not have a solution yet.

Thanks, Gary, I'll upload with that change.

This bug was fixed in the package lxc - 0.7.5-3ubuntu6

---------------
lxc (0.7.5-3ubuntu6) precise; urgency=low

  * debian/patches/0020-drop-cap-mac-admin.patch - to prevent containers
    from loading apparmor policy.
  * update 0016-nested-cgroups.patch: create cgroup dirs 0755 so that
    unprivileged users can read them (with lxc-ls).
  * debian/local/lxc-start-ephemeral: support in-line commands (LP: #914169)
 -- Serge Hallyn <email address hidden> Tue, 17 Jan 2012 10:55:20 -0600

@gary @serge - that dhcp vs dhcp3 thing is probably a case where the script needs to handle both: the dhcp client version changed between lucid and oneiric.

@serge Thank you!

@Robert IIUC we do both dhcp and dhcp3. My diff merely added a sudo.