[06:16] <pitti> Good morning
[07:14] <pitti> jibel: !!
[07:14] <pitti> $ ./run-from-checkout -d ~/ubuntu/tmp/ubuntu-calculator-app/ ~/ubuntu/tmp/com.ubuntu.calculator_1.3.283_all.click --- ssh -s ssh-setup/adb
[07:14] <pitti> adt-run [09:14:23]: test autopilot:  - - - - - - - - - - results - - - - - - - - - -
[07:14] <pitti> autopilot            PASS
[07:18] <jibel> pitti, \o/
[07:19] <pitti> jibel: still with one remaining hack, but I committed the "advertise suggested-normal-user=" capability fix which was missing
[07:22] <pitti> jibel: did you ever happen to figure out how to run powerd-cli in the background?
[07:22] <pitti> --setup-commands "(powerd-cli display on bright &) &"
[07:22] <pitti> even with this double fork it hangs eternally
[07:45] <jibel> pitti, usually I do "powerd-cli display on & " it hangs over adb but not with ssh
[07:49] <pitti> jibel: that still hangs for me
[08:27] <pitti> jibel: ugly, but working: http://paste.ubuntu.com/7725346/
[08:31] <jibel> pitti, ugly really :)
[08:32] <jibel> pitti, you'd probably want to force bash for disown. it is not a builtin of dash and I think adb shell calls sh -c
[08:34] <pitti> jibel: hm, it seems to call bash here
[08:34] <pitti> jibel: but adding another "bash -c" probably can't hurt
[08:43] <pitti> jibel: now I just need to disable the screen lock
[08:55] <jibel> pitti, BTW I'm sure you noticed bug 1335176
[08:55] <jibel> just confirming
[08:55] <pitti> jibel: yes, I did; next thing after I add the aa-clickhook bits
[08:56] <pitti> jibel: btw, might be easier to put your own /users git branch on alioth, and/or asking for membership in the autopkgtest alioth project
[08:56] <pitti> s/branch/repository/
[09:16] <jibel> pitti, for unlocking the device, there is a helper in unity8-autopilot
[09:16] <jibel> pitti, http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/tools/unlock-device
[09:17] <pitti> jibel: thanks; vila just pointed that out in #touch
[09:17] <jibel> ok
[10:03] <davmor2> Morning all
[11:05] <pitti> jibel: looking at (and simplifying) your nova script now; that doesn't have the floating-ip-create/floating-ip-associate stuff, isn't it necessary in general or just not for the canonistack?
[11:20] <jibel> pitti, I didn't try with hpcloud, but the private ip should be enoguht
[11:20] <jibel> enought
[11:20] <jibel> -t
[11:21] <pitti> | evan.dandrea@canonical.com-network network | 10.0.0.6
[11:21] <pitti> jibel: ^ that's what I get without a floating IP
[11:21] <jibel> pitti, right and can you ssh to 10.0.0.6?
[11:22] <pitti> jibel: no, as I said I need to add a public floating one
[11:22] <pitti> at least I haven't figured out how to use the 10.0.0.x one, supposedly you need some kind of VPN to the HP cloud?
[11:22] <pitti> ev, vila: ^ did you happen to figure out how to use these "private" IPs from HP cloud?
[11:23] <pitti> i. e. without floating-ip-create/floating-ip-associate ?
[11:27] <jibel> pitti, ah, you're right, we probably cannot for hpcloud. For canonistack I'm forwarding via chinstrap
[11:37] <pitti> jibel: detecting this automatically is a nuisance, so I suppose I'll just add an option to create/associate a floating IP
[11:46] <vila> pitti: you need a floating IP, juju may handle it for you otherwise  you're on your own
[11:46] <pitti> vila: *nod*
[12:44] <pitti> jibel: so with canonistack you can immediately ssh in after nova boot? with HP cloud it still takes a minute or so until ssh actually works, so I need to add an ssh wait loop
[12:46] <pitti> jibel: oh, that's already in adt-virt-ssh now, nevermind
[12:46] <pitti> HTTPSConnectionPool(host='region-a.geo-1.compute.hpcloudsvc.com', port=443): Max retries exceeded with url: /v2/11490006884368/servers (Caused by <class 'socket.error'>: [Errno 104] Connection reset by peer)
[12:46] <pitti> ERROR: Unable to delete any of the specified servers.
[12:46] <pitti> and I'm getting fun like that
[12:47] <vila> pitti, jibel: you're running into problems that has been solved in uci-engine testbed.by (floating IP, slow boot, transient hp errors, etc)
[12:48] <pitti> vila: ah, ncie
[12:48] <pitti> vila: so I suppose for CI we should use an ssh setup script which uses uci
[12:48] <vila> pitti: exactly
[12:49] <pitti> vila: you mentioned a script/package that sets these up, uci-vm or something?
[12:50] <vila> pitti: uci-vms yes, but the nova part is still uci-engine specific for now (and we're still trying to find the right cloud config  with webops... can't use nova in prodstack :-/)
[12:51] <pitti> vila: ack; the ssh setup scripts will be highly environment specific anyway, I mostly want to include some of them (adb, nova) as examples; although the adb one works quite nicely now
[12:51] <pitti> vila: so as soon as uci-vms is packaged somewhere, we can also include an ssh setup script which uses that
[12:52] <pitti> vila: while developers will want to use the adb setup script to reproduce errors locally, I suppose they'd rather use adt-virt-qemu for reproducing a package test failure than ssh with nova
[12:52] <pitti> few people actually have access to the HP (or other) cloud, and even if you do, it's a magnitude slower
[12:53] <pitti> vila: so ATM the nova script is mostly just good enough to prove that adt-virt-ssh can deal with this kind of testbed
[12:54] <vila> pitti: indeed, I don't want to stop you from exploring, just mentioning that hpcloud can be a can of worms (well, so can canonistack ;-)
[12:54] <vila> pitti: yup
[12:54] <pitti> heh, amen
[12:54] <pitti> vila: so to be on the same page, you are mostly looking for the ssh runner itself, but want to write your own setup script using uci-vms?
[12:57] <pitti> vila: so that I should make sure that the ssh  runner provides enough functionality, but the shipped nova setup script doesn't need to be production-stable?
[12:57] <vila> pitti: exactly
[12:58] <pitti> vila: très bien; then I won't waste too much time on it, let's rather package uci-vms at some point and then use that
[12:58] <vila> pitti: IP, login, ssh key
[12:58] <pitti> and treat it as a PoC
[12:59] <vila> pitti: it's packaged but only available in https://launchpad.net/~canonical-ci-engineering/+archive/ci-airline-phase-0 for now
[12:59] <vila> pitti: feedback welcome on the packaging in any case ;)
[13:00] <pitti> jibel: hmm, current nova script doesn't export "identity", how did that work for you?
[13:00] <pitti> jibel: also, I'm not entirely sure how to find the private key now, when just giving the keypair name; keypair-show only shows the pub key, but not its location
[13:01] <jibel> pitti, as I said I just tried with canonistack and I had my account already setup. So probably better rename nova -> canonistack  and just as a proof of concept than anything else :)
[13:02] <pitti> jibel: right, but even with canonistack the ssh runner shoudl just fail without an "identity="?
[13:02] <jibel> pitti, I can have a look later this week with another cloud
[13:02] <pitti> jibel: no worries, I'll add it
[13:03] <pitti> jibel: or perhaps rather just default to ~/.ssh/id_rsa.pub in virt-ssh, seems easier than doing it for every script
[13:04] <jibel> pitti, in my ssh/config I have Host XX.XX.XX.XX
[13:04] <jibel> User ubuntu
[13:04] <pitti> jibel: aah
[13:04] <jibel> IdnetityFile <some path>
[13:04] <jibel> and the proxy command for chinstrap
[13:05] <pitti> jibel: hm, true, if the script doesn't give identity=, ssh should default to the usual key by itself, so nevermind
[13:12] <pitti> jibel: nevermind, it was a bug in wait_for_ssh(), fixed now
[13:12] <pitti> jibel: now I get much further, I just run into unexpected stderr "sudo: unable to resolve host adt-nova-6ogg8l"
[13:13] <pitti> jibel: almost there :)
[13:16] <jibel> pitti, sorry for the bugs
[13:16] <pitti> jibel: no worries
[13:17] <pitti> jibel: just pondering how to set the host name properly, in the setup script or in virt-ssh
[13:19] <jibel> pitti, IMO in the setup script because usually it's already setup correctly. For example, on a phablet you won't change it, on an existing host it's already done, on canonistack cloud-init takes care of it, on lxc it's done in the template, ...
[13:20] <jibel> it seems to be really target specific
[13:20] <pitti> jibel: yeah, I agree
[13:20] <pitti> jibel: but I won't want to replicate the ssh wait loop, so I'm now reading http://docs.openstack.org/user-guide/content/user-data.html how to do this kind of setup at "nova boot" time instead of through ssh
[13:21] <pitti>   --meta <key=value>    Record arbitrary key/value metadata to /meta.js on the
[13:21] <pitti>                         new server. Can be specified multiple times.
[13:21] <pitti> that looks promising, if cloud-init can use that to fix /etc/hosts
[13:22] <pitti> (but this is really just a bug in cloud-init or the HP version of it, *grump*)
[13:22] <pitti> vila: ^ does uci-vms magically happen to fix that, too by chance?
[13:26] <vila> pitti: sorry, which one ? host name ? yeah, through cloud-init meta data, fuzzy memory there, I can't remember when I ran into issues there, I don't think I use it for nova though
[13:26] <pitti> vila: creating an instance foo-123 doesn't seem to add "foo-123" (the hostname) to /etc/hosts by default, so that e. g. sudo complains (apache and postfix will as well)
[13:26] <pitti> I suppose I want to set manage_etc_hosts
[13:27] <pitti> meh, this is really stuff that ought to "just work"
[13:28] <vila> pitti: hmm, I remember seeing that on juju instances but not on testbeds (and indeed I do use manage_etc_hosts)
[13:28] <vila> pitti: in uci-vms that is
[13:31] <pitti> meh, sometimes it feels like all that stuff makes it specifically hard to be used
[13:31] <pitti> so there is a --meta to set an individual key, but not a corresponding one for setting a cloud-config option !?
[13:31] <pitti> just a whole --user-data thing, but thanks no, I don't want to manage the *entire* configuration myself
[14:02] <pitti> jibel: I just pushed the revised nova script, which now also works for HP; would you mind testing adt-virt-ssh HEAD again against canonistack?
[14:05] <pitti> jibel: finished the libpng test, in a whopping 7:06 minutes (compare to schroot runner's 4 seconds..)
[14:07] <jibel> pitti, OTOH you can boot thousands in parallel :)
[14:07] <jibel> *of VMs
[14:07] <jibel> I'll test it in canonistack
[14:07] <pitti> yeah, still much room for optimization :)
[14:08] <pitti> jibel: ssh connnection sharing might help quite a bit with adb though, I'll still look into that
[14:08] <pitti> jibel: but many thanks for all your ground work here, nice to see all the puzzle pieces now
[14:08] <jibel> pitti, I tried quickly but the runner exited with an error 255 from ssh. If I try interactively it is fine.
[14:15] <pitti> jibel: do you have a -d (with both) output?
[14:16] <jibel> pitti, I don't.
[14:16] <jibel> I'll try again.
[15:55] <elopio> robotfuel: how can I run the tests you are working on?
[15:59] <robotfuel> elopio: the test is here https://code.launchpad.net/~chris.gagnon/+junk/lrt
[16:00] <elopio> robotfuel: branching...
[16:00] <elopio> robotfuel: why is it on your junk? maybe inside launchpad.net/ubuntu_autopilot_tests would be a good place for it.
[16:02] <robotfuel> elopio: ok
[16:03] <elopio> robotfuel: ok, what we will need in order to have it running for every image is a deb package.cd ..
[16:04] <elopio> robotfuel: do you know about packaging?
[16:04] <robotfuel> elopio: I use run-lrt.sh to start the test because launchpadlib is py2 and the other code is in py3.. so I can upload the bugs
[16:04] <robotfuel> elopio: yes, I can package it
[16:05] <elopio> robotfuel: and then we will have to add it to the archive: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#Going_through_MOTU
[16:05] <elopio> I'm doing the same for ubuntu_experience_tests, so it would be nice to do it together :D
[16:05] <robotfuel> sure
[16:07] <robotfuel> elopio: my plan for today is get the graph working for time to failure. then I will do the packaging and add more types of lrt tests.
[16:07] <elopio> ok, thanks. robotfuel: let me know if you need a hand or a review.
[16:07]  * elopio goes to get breakfast.
[17:47] <mapreri> bdmurray: is there a way to avoid the crichton bot to subscribe ~ubuntu-sponsor and add the tag patch on bugs where someone upload a debdiff? maybe a particular tag?
[17:53] <bdmurray> mapreri: 'bot-stop-nagging' should prevent that from happening
[17:54] <mapreri> bdmurray: ok, thanks
[18:27] <elopio> I'll upgrade my quassel server to trusty because it's unbearable. I might be away for some time.