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. :) -- 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
