functional-ssh-keys fails to import key from github

[Nicholas Skaggs]

Testing this manually I can verify the current tip of juju does import this key properly. It's unclear what may have changed that caused this test to begin failing.

$ $GOPATH/bin/juju import-ssh-key gh:jujubot
$ $GOPATH/bin/juju ssh-keys
Keys used in model: admin@local/default
37:de:0f:ff:58:61:ef:1f:1e:2f:b5:a2:a1:3c:f6:df (nskaggs@balloons)
47:2d:88:82:a6:84:9a:ca:44:3e:54:79:ed:bc:e4:64 (jujubot@github/19178372 # ssh-import-id gh:jujubot)
$ $GOPATH/bin/juju --version
2.0-rc2-xenial-amd64

[Nicholas Skaggs (nskaggs)]

Note, I re-ran the last version of juju that passed as well; http://juju-ci.vapour.ws:8080/job/functional-ssh-keys/84/console and it too now fails. I tested adding sleeps, etc as well.

I don't want to believe this is an issue with the machine runners, but it does also work on my local box. See attached. The job is set to run on lxd-slave-a only now.

[Nicholas Skaggs (nskaggs)]

Tried xenial-slave, it fails. Moved job to aws, that works: http://juju-ci.vapour.ws:8080/job/functional-ssh-keys/88/console.

Given local tests working in LXD, this seems quite odd.

[Nicholas Skaggs (nskaggs)]

Leaving job on aws for now, lowering to high since we have a workaround.

[Nicholas Skaggs (nskaggs)]

AWS job fails in a slightly different way:
http://juju-ci.vapour.ws:8080/job/functional-ssh-keys/88/console

[Nicholas Skaggs (nskaggs)]

ok, running on yakkety-slave

Joyent: http://juju-ci.vapour.ws:8080/job/functional-ssh-keys/108/
GCE: http://juju-ci.vapour.ws:8080/job/functional-ssh-keys/109/

works ^^

LXD: http://juju-ci.vapour.ws:8080/job/functional-ssh-keys/113/console

fails ^^

Azure: http://juju-ci.vapour.ws:8080/job/functional-ssh-keys/116/console
AWS: http://juju-ci.vapour.ws:8080/job/functional-ssh-keys/115/console

fails for different reason ^^

[Nicholas Skaggs (nskaggs)]

Testing again today locally on LXD and confirmed again the gh import works. I can also confirm the secondary issue of AWS also works. I cannot reproduce this at all on my machine.

$GOPATH/bin/juju remove-ssh-key juju-client-key
cannot remove key id "juju-client-key": may not delete internal key: juju-client-key
$ $GOPATH/bin/juju remove-ssh-key juju-system-key
cannot remove key id "juju-system-key": may not delete internal key: juju-system-key
$ $GOPATH/bin/juju ssh-keys
Keys used in model: admin@local/default
37:de:0f:ff:58:61:ef:1f:1e:2f:b5:a2:a1:3c:f6:df (nskaggs@balloons)
nskaggs@erielhonan:~/projects/go/src/github.com/juju/juju$ $GOPATH/bin/juju status
MODEL CONTROLLER CLOUD/REGION VERSION
default aws aws/us-east-1 2.0-rc2.1

The test is looking for "cannot remove key id "juju-client-key": may not delete internal key: juju-client-key", and aws indeed returns that. But the test gets back invalid key.

[Martin Packman (gz)]

To see why it's failing just add `--debug --verbose` to the run so the lower than info-level logging shows the full output from juju.

Currently, 1.25 fails because we added the standard CI key to jujubot, and the import doesn't like duplicates. Fixing that.