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

Bug #914169 reported by Gary Poster on 2012-01-10
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
lxc (Ubuntu)
High
Unassigned

Bug Description

William and Robert developed the lxc-start-ephemeral script to support a use case that the version in the package no longer supports, to the best of our knowledge.

Specifically, we need to be able to programmatically start ephemeral instances, send them a command and get the results, and then shut down the instance. The packaged version instead starts an instance, directs users to use lxc-console, and then starts lxc-monitor to wait for the instance to close.

We may have missed a way to use the existing approach for what we need, and are happy to talk about it.

If not, we believe that a nice solution would be to allow an option to lxc-start-ephemeral for a command that, if provided, is run instead of lxc-monitor. This command would be able to have a placeholder string; before the command is run, the placeholder would be replaced by the name of the ephemeral container. The command would inherit lxc-start-ephemeral's stdout and stderr. After the command finished, lxc-start-ephemeral would proceed to shut off the instance, just as it does now after lxc-monitor.

Thank you

Related branches

Serge Hallyn (serge-hallyn) wrote :

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?

Gary Poster (gary) wrote :

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.

Gary Poster (gary) on 2012-01-10
Changed in launchpad:
status: New → Triaged
importance: Undecided → High
tags: added: paralleltest
Serge Hallyn (serge-hallyn) wrote :

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

Changed in lxc (Ubuntu):
status: New → Triaged
importance: Undecided → High
Gary Poster (gary) wrote :

Thank you Serge. The switch from aufs looks good.

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

Gary Poster (gary) wrote :

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.

Serge Hallyn (serge-hallyn) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in lxc (Ubuntu):
status: Triaged → Fix Released
Robert Collins (lifeless) wrote :

@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.

Gary Poster (gary) on 2012-01-23
no longer affects: launchpad
Gary Poster (gary) wrote :

@serge Thank you!

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers