canonical-ci-engineering team mailing list archive

[Evan Dandrea <evan.dandrea@xxxxxxxxxxxxx>]

At the request of Francis and Chris, I've asked IS to create a role
account on Canonistack for our team. This account should be used for
services that are not yet ready for running on Prodstack. This will be
things like:

 * Staging deployments that we need shell access to.
 * CI of our infrastructure.
 * The core-apps Jenkins.
 * Services in development that need to stay running (and thus would
otherwise tie up your own account).

We will likely find it best to move some of these categories over to
Prodstack in time, so please make sure what you're deploying is
getting closer and closer to being ready for the webops team to pick
up.

Please isolate services with separate juju bootstrap nodes so that we
can tear down entire services without needing to surgically terminate
nodes. juju-deployer makes managing this sort of arrangement easy, so
lets use that.

I'd appreciate it if you could keep an eye on `nova absolute-limits`
when building out. If we're running out of cores or instances, let me
know and I'll ask IS to increase our resource limits.

Make sure your juju bootstrap node is at least a m1.small, otherwise
you're going to run into http://pad.lv/1227533. If you're running juju
bootstrap manually (which you *don't* need to do with juju-deployer),
this is:

juju bootstrap --constraints="mem=1G"

== Instructions ==

Branch lp:ci-engineering-canonistack. Source either
canonistack/novarc_lcy01 or canonistack/novarc_lcy02, depending on
which region you want to use. I'd very much recommend using lcy02 as
our primary region. It's running a newer version of OpenStack, and
because it's not the default environment suffers less from the tragedy
of the commons.

Next, add an environment to juju/environments.yaml for your service
and commit that change to bzr. export JUJU_HOME="$(readlink -f
juju/environments.yaml)" to point at the team environment instead of
your personal one.

Branch lp:juju-deployer/darwin and have a look at the sample configs
in configs/. Construct a configuration of your own back in the
ci-engineering-canonistack branch under the juju-deployer/ directory
and commit that.

Back in your darwin branch of juju-deployer run the following:
virtualenv --system-site-packages deployer
./deployer/bin/easy_install juju-deployer

You'll now have a copy of juju-deployer at
./deployer/bin/juju-deployer. To deploy your service, run:

./deployer/bin/juju-deployer -c
$path_to_ci_engineering_canonistack/juju-deployer/your-config.yaml

If this proves to be too complicated and error prone, we can look at
adapting the U1 team's convenience layer on top of juju-deployer:
https://bazaar.launchpad.net/~ubuntuone-pqm-team/canonical-is-charms/ubuntuone-servers-deploy/view/head:/README

Thanks. Let me know if you run into any problems and do share any
tricks you find with the rest of the team. :)