Diff for "Running/LXC"

Not logged in - Log In / Register
Differences between revisions 95 and 113 (spanning 18 versions)
⇤ ← Revision 95 as of 2012-05-03 08:10:47 →
Size: 5725
Editor: wgrant
Comment: Fixes
← Revision 113 as of 2021-12-10 15:20:27 → ⇥
Size: 0
Editor: cjwatson
Comment: use LXD instead; see https://launchpad.readthedocs.io/en/latest/running.html
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This page explains how to set up and run Launchpad (for development) inside an LXC container.

= Why? =

Launchpad development setup makes significant changes to your machine; it's nice to be unaffected by those when you're not doing such development. Also, multiple containers can be used to work around Launchpad's limitations regarding concurrent test runs on a single machine.

These instructions should work on Ubuntu 12.04 LTS and later. Older versions of LXC are significantly less reliable and polished, so if you've used a version of LXC older than 12.04 LTS's final release on your development machine, you'll want to remove `/var/cache/lxc` first to ensure that you don't have a broken cache.

= Make a LXC =

 1. Install LXC's userspace tools.
 {{{
sudo apt-get install lxc
}}}

 1. Create a container. You might want to use an HTTP proxy or alternate Ubuntu mirror; you can do this by specifying an http_proxy or MIRROR environment variable after `sudo`.
 {{{
sudo lxc-create -t ubuntu -n lpdev -- -r lucid -a i386 -b $USER
}}}

 1. Start the container. You'll probably see a few early warnings about boot processes dying -- they're normal and can be ignored as long as you end up at a login prompt.
 {{{
sudo lxc-start -n lpdev
}}}
    
 1. '''[Inside the container]''' Log in with your normal username and password. You'll have full sudo powers.

 1. '''[Inside the container]''' Get the container's IP address from the console. You'll generally want to `ssh` in for convenience and better termcap functionality, and the default Ubuntu LXC dnsmasq setup doesn't provide name resolution from the host
 {{{
ip addr show dev eth0 | grep 'inet'
}}}

 1. '''[Inside the container]''' Install some additional packages needed before running `rocketfuel-setup` and the rest of the Launchpad setup process.
 {{{
# rocketfuel-setup assumes that bzr is already installed.
apt-get install bzr
# PostgreSQL will fail to create a cluster during installation if your
# locale is configured but not supported by the container, so install
# the relevant language pack (this example is only good for English).
# You need to do this if the prior apt commands spewed locale warnings.
#
# If you didn't do this before running rocketfuel-setup, you'll want
# to run `sudo pg_createcluster 8.4 main` afterwards to fix the damage.
apt-get install language-pack-en
}}}

 1. '''[Inside the container]''' Shut down by running `poweroff` inside the container, and you should eventually be dumped back out to your host system. If it looks like it's hanging, force it to stop with `sudo lxc-stop -n lpdev` on the host.
 
 1. Start it up again, headless this time (`-d`). The same IP address will be used, so you don't need console access.
 {{{
sudo lxc-start -n lpdev -d
}}}

 1. `ssh <IP address obtained above>` to connect to the VM. If your SSH key is in your local `authorized_keys` file you shouldn't be prompted for a password, as your home directory (including public and private keys) is bind mounted into the container. `ssh -A` might give you a better agent experience when dealing with Launchpad code hosting.

 1. '''[Inside the container]''' You can now follow the normal [[Getting|LP installation instructions]]. Be warned that changes in your home directory will also be seen outside the container and vice versa. If your home directory already has a Launchpad work area set up you'll want to run `rocketfuel-setup --no-workspace` to avoid trying to recreate it, but all subsequent steps are still required.

 1. Follow [[Running/RemoteAccess]] to set up access from the host's applications to the container's Launchpad instance.


= Problems =

== rabbitmq does not start up ==

rabbitmq may fail to start up. If that happens it appears to be a [[http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2010-April/007024.html|mnesia glitch]] best sorted by zapping mnesia.
 {{{
sudo rm -rf /var/lib/rabbitmq/mnesia/rabbit/*
sudo service rabbit-mq start
}}}

== database-developer-setup fails, and thinks you are on Postgres 8.2 ==

As noted above, if you have a localised (non-C) locale, you need to install your specific language pack. For instance, if your computer has a localised English locale, use this:

{{{
apt-get install language-pack-en
}}}

== lxc-start hangs ==

[[http://paste.ubuntu.com/772517/|The symptom looks like this]]. It hangs after that.

No fix or workaround identified yet, other than making a new lxc container.

To debug, try '''{{{lxc-start -n $containername -l debug -o outout}}}''' and look at outout.

== DNS fails inside the container ==

After restarting in daemon mode and logging in as a regular user, DNS was not working.
Ensure there is a nameserver in the container's /etc/resolv.conf, which is created at startup by resolverconf. Stopping and starting the container solved the problem.

== Random flakiness ==

Using lxc via juju I ran into all sorts of problems with DNS, version mismatches, etc. Since it was via juju I wasn't able to muck around with /etc/resolv.conf (the damage was done before I got the chance to ssh to the guest.) I found {{{sudo rm -rf /var/cache/lxc}}} solved the problem. It is rather brutal but worked. Of course the next run took a long time as all of that previously cached stuff had to be refetched.

== Other problems ==

If other lxc users don't have an idea (known lxc users as of this writing include lifeless, wgrant, frankban and gary_poster) try asking hallyn or Spamaps on #ubuntu-server on freenode.

= References =


= Alternatively =

You can also run in a [[Running/Schroot|chroot]] environment or a [[Running/VirtualMachine|VM]].