lp:juju-core/trunk r2644 broke 1.19.1
John Meinel
john at arbash-meinel.com
Fri Apr 18 18:04:41 UTC 2014
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 <john at arbash-meinel.com> 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 <
> curtis at canonical.com> 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
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140418/f5eaf16b/attachment.html>
More information about the Juju-dev
mailing list