I'm not sure what happened, because r2655 shows it passing on all targets, but the actual change was only really related to MaaS.
I'm still going to try and see if I can get the CI tests to run locally. If I can get the steps to set up pretty clear, then it should be easier for us to reproduce what CI sees. John =:-> On Fri, Apr 18, 2014 at 10:04 PM, John Meinel <[email protected]>wrote: > I did eventually manage to run the CI tests, though there are some > oddities: > > 1) You have to set JUJU_HOME and SCRIPTS, though that is in the docs > > 2) You have to set LOCAL_JENKINS_URL to the ec2 instance > > 3) You have to set WORKSPACE, but you *also* have to have $PWD already be > in WORKSPACE. > > 4) If you made a mistake with $PWD it also has the nice properties of rm * > -rf, which wipes out wherever you were running it. > > 5) Even though I've set JUJU_HOME to $HOME/dev/juju-ci/cloud-city, the > first thing it does is override JUJU_HOME with $HOME/cloud-city (or for > manual source $HOME/cloud-city/ec2rc.) > > 6) You can edit the ec2rc and environments.yaml so that it launches with > your own credentials, so that you don't consume resources in the CI group. > > 7) It uses a special SSH key which comes in cloud-city. But by default the > file is rw-rw... which is too open for SSH to let you use the key. So you > have to chmod 600 the staging_id_rsa (and you can 644 the > staging_id_rsa.pub). > We don't give good feedback that a key might be being ignored, I only > found out because I went to "ssh-add" it to make sure it was available. You > can probably change the environments.yaml to a) not include a key, or b) > include your own key, or c) ssh-add the existing SSH key from cloud-city. > > 8) You need the CI repository for the charms the tests run. Curtis was > kind enough to tar them up for me here: > http://people.canonical.com/~curtis/repository.tgz > (You'll need Canonical SSO to get access to that file, I believe) > You need to set CHARM_PREFIX="local:precise/", and it requires the files > to be in $HOME/repository (I used symlinks) > > 9) You can get detailed information by doing "/--show-log/--debug/" in 2 > of the common files (one is bash, one is python) > > 10) You have to have the new revision published to a testing bucket. I > haven't finished working out where I want to put it for my testing. There > is a script for this in "publish-revision" but it does explicitly hard-code > "s3://juju-dist/testing". > > So that is as far as I got. I feel close, but I can't *quite* run the CI > test suite locally. > > John > =:-> > > > > On Fri, Apr 18, 2014 at 4:39 PM, John Meinel <[email protected]>wrote: > >> Note also that you're at your 20 instance limit in EC2. From what I can >> tell you have a bunch of leaked manually provisioned machines, (looking at >> euca-describe-instances and seeing what GROUP or job_name they have.) >> >> 2 in "default" group >> 7 in "manual-juju-test" >> 7 in juju-juju-ci3-* machines (presumably this is an actual Juju >> environment named juju-ci3) >> >> And some other random ones, like Jenkins itself. >> >> John >> =:-> >> >> >> >> On Thu, Apr 17, 2014 at 8:59 PM, Curtis Hovey-Canonical < >> [email protected]> wrote: >> >>> lp:juju-core/trunk r2644 introduced a regression. >>> upgrade-juju fails on all providers >>> https://bugs.launchpad.net/juju-core/+bug/1309108 >>> >>> Unit agents are not upgrading. I attacked logs from all the failed tests. >>> >>> -- >>> Curtis Hovey >>> Canonical Cloud Development and Operations >>> http://launchpad.net/~sinzui >>> >>> -- >>> Juju-dev mailing list >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >> >> >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
