=== wedgwood is now known as wedgwood_away
[01:34] <StevenK> wgrant: httplib2.debuglevel = 1 produces 200MiB of output
[01:34] <StevenK> steven@undermined:~% tail -n 1 qa-mawson-output | wc -c
[01:34] <StevenK> 206338762
[01:35] <wgrant> As you'd expect
[01:48] <StevenK> wgrant: Blah. http://pastebin.ubuntu.com/5756839/
[02:05] <StevenK> wgrant: That's 3 POSTs in a row, so I don't know what the hell lplib is doing
[02:07] <wgrant> StevenK: What are the responses?
[02:08] <StevenK> reply: ''
[02:08] <StevenK> For the first one
[02:08] <StevenK> 502 for the second
[02:24] <StevenK> reply: '' for the third
[03:59] <StevenK> wgrant: reply: '' and 502s make me sad
[04:00] <wgrant> StevenK: Indeed
[04:00] <wgrant> StevenK: The second call is probably a retry of the 502
[04:00] <StevenK> reply: '' was first
[04:00] <StevenK> So I suspect all but the first are retries
[04:05] <wgrant> StevenK: Wasn't that the response to the initial GET, not the POST?
[04:05] <wgrant> Oh, or you mean that there was a third POST after your paste?
[04:05] <StevenK> No
[04:06] <StevenK> send: 'POST /devel/ubuntu/raring/i386 HTTP/1.1\r\nHost: api.qastaging.launchpad.net\r\nContent-Length: 71817072\r\nAuthorization: OAuth realm="OAuth", oauth_nonce="73131629", oauth_timestamp="13710006
[04:06] <StevenK> reply: ''
[04:06] <StevenK> connect: (api.qastaging.launchpad.net, 443)
[04:06] <StevenK> send: 'POST ...
[04:43] <StevenK> wgrant: So I'm not sure what would cause an empty reply to a POST
[04:49] <wgrant> StevenK: There was no separate status?
=== tasdomas_afk is now known as tasdomas
[05:03] <StevenK> wgrant: No status, no headers, nothing
[05:54] <StevenK> wgrant: I'm a bit stuck where I should fix this invalid transition critical that you filed a dupe of
[05:55] <wgrant> StevenK: What are the options?
[05:56] <StevenK> wgrant: We can hack lazr.jobrunner to log "Skipping Completed job" in runJob, but I don't think we can impose a cronscript to rip out the entry from the rabbit queue when it completes a job
[05:57] <StevenK> We could also do that in lp.services.job.runner, rather than lazr.jobrunner
[05:58] <wgrant> StevenK: No, we can't dequeue the job
[05:58] <wgrant> We have to handle it once celery receives it
[05:59] <StevenK> Right
[05:59] <StevenK> So runJob can just log it and move on
[06:00] <wgrant> StevenK: Probably. The normal jobrunners only fetch jobs that are WAITING, so it would make sense for celery to skip them similarly
[06:00] <wgrant> Before it even gets into the job ode
[06:00] <wgrant> code
[06:01] <StevenK> Well, we don't have that luxury, since we're pulling jobs off the queue
[06:03] <wgrant> I know
[06:03] <wgrant> But you can possibly check as soon as you pull a job off the queue
[06:03] <wgrant> The job should ideally be thrown away before we reach the common celery+cronjob code
[06:05] <StevenK> wgrant: I can do it in acquireLease() which should be early enough
[06:07] <StevenK> wgrant: But is probably the wrong place. lp.services.job.runner.BaseJobRunner.runJob() should be okay to log and return
[06:10] <wgrant> StevenK: Sounds reasonable
[07:02] <StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/no-completed-jobs-for-celery/+merge/168859
=== tasdomas is now known as tasdomas_afk
=== tasdomas_afk is now known as tasdomas
=== Nigel_ is now known as G
=== tasdomas is now known as tasdomas_afk
=== wedgwood_away is now known as wedgwood
=== olli_ is now known as olli
[19:02] <fginther> what causes a new password to be generated for access to a private ppa?
[19:02] <fginther> I'm working with some ppa automation which accesses private ppas. I'm seeing an issue where sometimes it works and sometimes it gets a 401. While debugging I've noticed that the password is different each time. Each time the script runs, it uses the same credentials, but a different cache dir
=== tasdomas_afk is now known as tasdomas
=== tasdomas is now known as tasdomas_afk
[21:10] <fginther> please disregard my earlier question. It doesn't look like the ppa access was setup correctly.
=== wedgwood is now known as wedgwood_away