launchpad development|
Size: 5402
Comment: Note that pre-12.04 LTS LXCs are likely to have created a flaky cache
|
Size: 5600
Comment: back to i386 and add a note
|
| 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 a LXC. | This page explains how to set up and run Launchpad (for development) inside an LXC container. LXC is the recommended environment for doing Launchpad development in. We are currently transitioning to using LXC for our Continuous Integration setup. |
| Line 5: | Line 5: |
| Launchpad development setup makes significant changes to your machine; its nice to be unaffected by those except when you are actually doing such development. Also, Launchpad has some limitations on concurrent testing per-machine and so forth - multiple containers can be used to work around this. | 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. |
| Line 7: | Line 7: |
| These instructions should work on Ubuntu 12.04 LTS and later. 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` to ensure that you don't have a broken cache. | 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. |
| Line 9: | Line 9: |
| = Make a LXC = | = Create an LXC container = |
| Line 11: | Line 11: |
| 1. Install lxc | 1. Install LXC's userspace tools. |
| Line 16: | Line 16: |
| 1. Create a container. In the following commands, replace ''$username'' with your username on the host. | 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`. (You can use amd64 if you prefer, although it will use more RAM.) |
| Line 18: | Line 18: |
| sudo lxc-create -t ubuntu -n lpdev -- -r lucid -a i386 -b $username | sudo lxc-create -t ubuntu -n lpdev -- -r precise -a i386 -b $USER |
| Line 21: | Line 21: |
| * If you want a proxy: {{{ sudo http_proxy=http://host:port/ lxc-create -t ubuntu -n lpdev -- -r lucid -a i386 -b $username }}} * And if you want to set a custom mirror, similar to http_proxy, but set MIRROR= instead. 1. Start the container |
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. |
| Line 32: | Line 25: |
| Ignore the warning about openssh crashing - it restarts on a later event. | |
| Line 36: | Line 28: |
| 1. '''[Inside the container]''' Grab the IP address (handed out via LXC's dnsmasq DHCP server) - you may wish to SSH in rather than using the console (seems to have better termcap experience). | 1. '''[Inside the container]''' Install various packages needed to be able to connect easily (avahi-daemon) and run `rocketfuel-setup` [[#postgresql-locale-breakage|successfully]]. |
| Line 38: | Line 30: |
| ip addr show dev eth0 | grep 'inet' }}} |
sudo apt-get install avahi-daemon bzr language-pack-en }}} |
| Line 41: | Line 33: |
| 1. '''[Inside the container]''' Install some additional packages we'll need to run rocketfuel-setup etc. Most people with an English locale will simply want to do this: `apt-get install bzr language-pack-en` If your locale is not English, or if you want more details, try/read this. {{{ apt-get install bzr # if you have a localised (non-C) locale: # not doing this will cause postgresql to fail to install, with -hilarious- results as database-developer-setup will think you have 8.2 installed. # You can tell if you need this if the prior apt commands spewed locale warnings. # Pick your specific language pack. apt-get install language-pack-en }}} 1. To stop it now run 'poweroff' in the lxc container. If it works smoothly, you will eventually be dumped back out to your host system. If it looks like it is hanging, then use "{{{sudo lxc-stop -n lpdev}}}" in the host. |
1. '''[Inside the container]''' Shut down by running `sudo 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` from outside the container. |
| Line 55: | Line 35: |
| 1. Start it up again, headless this time (-d). The previous IP address will be used. | 1. Start it up again, headless this time (`-d`). The same IP address will be used, so you don't need console access. |
| Line 60: | Line 40: |
| 1. ssh <vm IP address> to connect to the VM. Your ssh key is already present because of the bind mount to your home dir, though using ssh -A might give you a better ssh agent experience. | 1. `ssh -A lpdev.local` to connect to the container. 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. The `-A` permits you to access Launchpad code hosting from within the container without needing to reenter passphrases. |
| Line 62: | Line 42: |
| 1. You can now follow the [[Getting|getting-started]] on LP instructions. Be warned that changes in ~ will affect you outside the container. You will want to run rocketfuel-setup with --no-workspace if your home already has a workarea. You may need to run utilities/launchpad-database-setup separately too. | 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. |
| Line 64: | Line 44: |
| 1. You probably want to follow [[Running/RemoteAccess]] has a discussion for how you can configure things so your non-container browser can access web pages from within the container. | 1. Follow [[Running/RemoteAccess]] to set up access from the host's applications to the container's Launchpad instance. |
| Line 66: | Line 46: |
| = Problems = | = Troubleshooting = <<Anchor(postgresql-locale-breakage)>> == launchpad-database-setup fails == PostgreSQL will fail to create a cluster during installation if your locale is configured to something non-C but not supported by the container, so you need to install the relevant language pack. You will know you need to do this if bzr or apt commands have been spewing locale warnings. For instance, if your computer has a localised English locale, use this: {{{ apt-get install language-pack-en }}} If you didn't install the language pack before running rocketfuel-setup, you'll need to run `sudo pg_createcluster 8.4 main` afterwards to fix the damage. |
| Line 76: | Line 77: |
| == 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 }}} |
|
| Line 90: | Line 83: |
| To debug, try '''{{{lxc-start -n $containername -l debug -o outout}}}''' and look at outout. | To debug, try '''{{{lxc-start -n $containername -l debug -o outout}}}''' and look at output. |
This page explains how to set up and run Launchpad (for development) inside an LXC container. LXC is the recommended environment for doing Launchpad development in. We are currently transitioning to using LXC for our Continuous Integration setup.
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.
Create an LXC container
- Install LXC's userspace tools.
sudo apt-get install lxc
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. (You can use amd64 if you prefer, although it will use more RAM.)
sudo lxc-create -t ubuntu -n lpdev -- -r precise -a i386 -b $USER
- 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
[Inside the container] Log in with your normal username and password. You'll have full sudo powers.
[Inside the container] Install various packages needed to be able to connect easily (avahi-daemon) and run rocketfuel-setup successfully.
sudo apt-get install avahi-daemon bzr language-pack-en
[Inside the container] Shut down by running sudo 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 from outside the container.
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
ssh -A lpdev.local to connect to the container. 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. The -A permits you to access Launchpad code hosting from within the container without needing to reenter passphrases.
[Inside the container] You can now follow the normal 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.
Follow Running/RemoteAccess to set up access from the host's applications to the container's Launchpad instance.
Troubleshooting
launchpad-database-setup fails
PostgreSQL will fail to create a cluster during installation if your locale is configured to something non-C but not supported by the container, so you need to install the relevant language pack.
You will know you need to do this if bzr or apt commands have been spewing locale warnings.
For instance, if your computer has a localised English locale, use this:
apt-get install language-pack-en
If you didn't install the language pack before running rocketfuel-setup, you'll need to run sudo pg_createcluster 8.4 main afterwards to fix the damage.
rabbitmq does not start up
rabbitmq may fail to start up. If that happens it appears to be a mnesia glitch best sorted by zapping mnesia.
sudo rm -rf /var/lib/rabbitmq/mnesia/rabbit/* sudo service rabbit-mq start
lxc-start hangs
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 output.
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
