With the following diff applied, I was able to successfully get the CI Engine deployed¹ in the Juju local provider:
http://paste.ubuntu.com/7232485/ It took 22 minutes. The test runner was far more promising, taking all of 4 minutes. That's the *entire* deploy.py. From "Deploying services..." it was 2 minutes, 45 seconds. I have the lxc-clone and lxc-clone-aufs options set and an SSD, but it's running under a VM (single core, 2GB of RAM, virtio). As Celso has proven elsewhere that VirtualBox is slow as molasses, take this figure with a grain of salt. This should be much, much faster on a real machine and with hazmat's btrfs-backed lxc goodness. If you're keen on trying for yourself: ~/.juju/environments.yaml local: type: local default-series: precise lxc-clone: true lxc-clone-aufs: true admin-secret: secret Packages (trusty): liblxc0 1.0.0~alpha1-0ubuntu11 liblxc1 1.0.3-0ubuntu1 lxc 1.0.3-0ubuntu1 lxc-templates 1.0.3-0ubuntu1 python3-lxc 1.0.3-0ubuntu1 juju-core 1.18.0-0ubuntu13.10.1~juju1 juju-deployer 0.3.4-0ubuntu1 juju-local 1.18.0-0ubuntu1 juju-mongodb 2.4.9-0ubuntu3 python-jujuclient 0.17.5-0ubuntu2 I sourced my HP credentials, so everything can talk to Swift, Glance, and Nova in the case of the Test Runner. I exported JUJU_ENV=local. Thanks, Evan ¹ But a ticket did fail to make it past image building, thanks to LXC sharing the kernel: [2014-04-11 10:08:52,446] image_build:INFO:loading nbd... [2014-04-11 10:08:52,613] image_build:ERROR:error running ['modprobe', 'nbd']: We'll need to explicitly permit that, or do it as part of deploy.py when we're running under the local provider. -- Mailing list: https://launchpad.net/~canonical-ci-engineering Post to : [email protected] Unsubscribe : https://launchpad.net/~canonical-ci-engineering More help : https://help.launchpad.net/ListHelp
