[00:23] <wgrant> ev: What is this launchpadlib-using web service doing?
[08:22] <ev> wgrant: creating bug reports for error reports on errors.ubuntu.com
[08:22] <ev> wgrant: there will be a "create" link wherever there isn't a LP bug report already in the "report" column
[08:23] <ev> clicking on that will take you through the OAuth dance, then create a new launchpad bug for the data in the error tracker (daisy.ubuntu.com)
[08:24] <ev> we thought about just doing this automatically - and indeed I thought that was the consensus at UDS, but other developers don't want to buried in Launchpad bugs any more than they already are
[08:24] <ev> so they would prefer it to be a semi-manual operation
[08:26] <ev> I had it first implemented as a tastypie API, called asynchronously from YUI, but then realised it'd probably be better to avoid having a bot user's credentials do the heavy lifting
[08:35] <wgrant> ev: Well, anyone granting a non-read-only LP OAuth token to a non-desktop application should probably have their privileges revoked, since they provide insufficient scope restriction facilities.
[08:37] <ev> wgrant: it only holds the keys in cookies. In practice, I don't see then how it's different than a desktop application
[08:37] <wgrant> eg. any writable token from an archive admin can root every Ubuntu machine in the world in fairly short order.
[08:39] <ev> wgrant: would your suggestion then be to go back to creating a bot user for this sort of thing?
[08:53] <wgrant> ev: I'm not quite sure.
[08:54] <wgrant> ev: But teaching people that it's OK to give random webapps access to their Launchpad accounts is not a good idea.
[08:54] <wgrant> (Launchpad could make this a non-issue by actually providing sensible OAuth functionality, but today it does not)
[09:11] <ev> sure, but alas it does not and I have deadlines to meet :)
[09:12] <ev> (and other work items dependent on being able to associate an error with a bug number)
[10:19] <lifeless> wgrant: what do you mean by sensible - tightly controlled actions ?
[10:20] <lifeless> ev: Why did you stop using a service account? they are the 'stock' answer we have for that sort of thing...
[10:27] <cjwatson> wgrant: What about ~ubuntu-archive-robot, then (which isn't actually being used yet, but I'd like it to be soon enough to replace stuff currently being run with direct DB access on cocoplum and should-be-automated stuff run by hand)?  I discussed that with sinzui a while back and we agreed that it wasn't really any worse than the present situation ...
[10:31] <cjwatson> (Restricting its scope to particular API requests, say, might be nice but given the kinds of things we need to do I'm not sure it would actually be a meaningful security improvement ...)
[10:34] <cjwatson> If it weren't for bug 1006917, that could (I think reasonably) be running fully-automatic auto-syncs from Debian right now.
[10:34] <_mup_> Bug #1006917: Distribution archive owners cannot necessarily copy packages <feature> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1006917 >
[10:39] <ev> lifeless: at the time it seemed like having the bug created by the individual clicking the link on errors.ubuntu.com was the sensible thing to do, but equally because the documentation (https://help.launchpad.net/API/launchpadlib#Authenticated_access_for_website_integration) didn't say to not do it and I didn't find anything saying that I should definitely use a bot account for this sort of thing.
[12:01] <wgrant> lifeless: On any other OAuth service the tokens grant partial access depending on what the application requires.
[12:01] <wgrant> cjwatson: It's clearly not a problem for a service that is intended perform archive administration tasks to possess permission to perform archive administration tasks.
[12:02] <wgrant> cjwatson: It is probably a problem for a widely-accessed bug filing service to possess them.
[14:47] <ev> wgrant, lifeless: so to be clear, I should be using a bot account for this? Any thoughts on whether clicking the "create bug" link should also sit behind open ID, or can we get away with letting anyone click on it? It's javascript, so presumably crawlers wouldn't hit it.
[19:48] <lifeless> ev: what data will it ask the user for ?
[19:49] <lifeless> ev: I suspect my answer is going to be 'use a bot and do the thing automatically with no button presses at all'
[19:49] <ev> lifeless: it doesn't need to ask the user anything. It will take the error metadata and create a bug, then write that into the duplicates db
[19:49] <lifeless> ev: so why does there need to be a button ?
[19:50] <lifeless> wgrant: I don't suppose you got the LEP together on friday afternoon after I EOD'd ?
[19:50] <ev> yeah, I thought doing it automatically was the understanding coming out of UDS, but developers were against flooding Launchpad with more bug reports that they wont be able to process
[19:50] <ev> and it's really only needed for the things we'll fix
[19:51] <ev> so if a crash happens once, creating a bug for it is just noise
[19:52] <lifeless> ev: there is a button for that: 'invalid'
[19:52] <ev> the specific problem this is trying to solve is having a way of marking a crash as being fixed. We also discussed putting SHA-1 hashes in the changelog, but that was overwhelmingly rejected
[19:52] <ev> lifeless: sure, but that requires human processing :)
[19:52] <ev> SHA-1 hashes of the crash signature, that is. So you could avoid creating a bug report entirely.
[19:53] <lifeless> so the workflow is at-or-after fixing the issue, someone realises its on errors.ubuntu.com but didn't have a bug
[19:54] <lifeless> they click the button, which creates a bug, they go to the bug, mark it a duplicate of the one they used during their upload, and the system then knows its fixed ?
[19:54] <lifeless> if someone is working from errors.u.c, they might start with the button clicking
[19:55] <ev> half of that. Someone sees an issue on errors.ubuntu.com, they fix it. They click the "create bug button" then reference it in the debian/changelog and upload
[19:55] <lifeless> ev: folk *will* fix things accidentally ;)
[19:55] <ev> that then goes into our facy bugs -> fixes UI
[19:56] <lifeless> ev: whats the workflow when someone fixes it without telling the system in advance ?
[19:56] <ev> lifeless: sure, and indeed that should do the right thing when faced with the scenario you've presented
[19:56] <ev> it can do exactly that. Follow the bug to its parent and write that into the DB
[19:57] <lifeless> ok
[19:59] <ev> or follow the bug to its parent as it's reading the bug -> fixed binary versions data later on, since the duping of the created bug could happen much later in time
[19:59] <lifeless> cool
[19:59] <lifeless> ok
[20:00] <lifeless> uhm
[20:00] <lifeless> what do you think folk would feel if:
[20:00] <lifeless>  - the top10 frequency signatures automatically got bugs made
[20:01] <lifeless>  - other signatures allow you to specify a bug # or request one get made
[20:01] <lifeless> ev: btw, you can't safely use launchpadlib within a web service.
[20:02] <lifeless> ev: you need to farm it out to a single threaded own-cache-owning worker.
[20:02] <ev> eep
[20:02] <ev> I think creating bugs for the top 10 frequency signatures automatically is reasonable
[20:03] <lifeless> oh, I forgot, its (privisionally) fixed.
[20:03] <lifeless> bug 459418
[20:03] <_mup_> Bug #459418: Cache is not safe for concurrent use (by processes or threads) <lp-foundations> <oem-services> <Launchpad itself:Triaged> <lazr.restfulclient:Fix Committed by jml> < https://launchpad.net/bugs/459418 >
[20:03] <lifeless> I don't think its been released.
[20:03] <ev> beauty of web services - I don't have to wait for it to be
[20:03] <lifeless> thats in lazr.restful
[20:04] <lifeless> erm restfulclient
[20:04] <lifeless> so yes, you do ;)
[20:04] <lifeless> or you need to run your own tarball
[20:04] <ev> well I mean I can throw it into a PPA and add it to the dependencies package for webops
[20:05] <ev> of course, it might be released faster than the PPA builds it :-P
[20:08] <ev> ah, but presumably that's blocked on bug 513116
[20:08] <_mup_> Bug #513116: launchpadlib is not thread-safe <lp-foundations> <oem-services> <Launchpad itself:Triaged> <launchpadlib :Triaged> < https://launchpad.net/bugs/513116 >
[20:10] <lifeless> releasing lazr.restfulclient blocked? no. But using launchpadlib in a web server - yes, thats blocked ;)
[20:11] <lifeless> ev: if I may make a suggestion
[20:11] <lifeless> ev: for make-a-bug, use a parameterised link directly to launchpad, and the user can go through the filing form themselves.
[20:12] <lifeless> ev: for automatically-make-it do it in celery/rabbit consumer/backend script/whatever
[20:13] <lifeless> ev: its not quite as nice, but it will be a lot faster to put together, and you can iterate later
[20:14] <ev> lifeless: we need to be able to write the bug number into Cassanda. We could put an input box there, but that is quite ugly. It sounds like celery is the best option until launchpadlib becomes thread safe.
[20:14] <lifeless> ev: 'forever'
[20:14] <ev> hahaha, oh dear
[20:15] <ev> well, using celery isn't a bad thing
[20:15] <lifeless> sure :)
[20:20] <lifeless> ev: anyhow, does that give you enough to go on?
[20:20] <ev> lifeless: it surely gives me enough to keep me busy for a while :)
[20:20] <lifeless> ev: was my reply to the just-in-time thread sane ?
[20:20] <ev> lifeless: the librarian one?
[20:21] <lifeless> yes
[20:21] <ev> yes, and thank you for following up to that
[20:21] <lifeless> my pleasure
[20:21] <lifeless> it had slipped past me for a bit
[20:23] <ev> and a big thanks for pointing out that we want to delivery code to execute from this thing, so it's a security problem we'll have to solve one way or another. That had slipped my mind.
[20:24] <lifeless> yeah, it makes quie a difference to the incremental overheads :)