lp:juju-core/trunk r2644 broke 1.19.1

[John Meinel]

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 <john at arbash-meinel.com>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 <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/20140419/4f42e379/attachment-0001.html>