/srv/irclogs.ubuntu.com/2012/06/09/#launchpad-dev.txt

wgrantev: What is this launchpadlib-using web service doing?00:23
evwgrant: creating bug reports for error reports on errors.ubuntu.com08:22
evwgrant: there will be a "create" link wherever there isn't a LP bug report already in the "report" column08:22
evclicking 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:23
evwe 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 are08:24
evso they would prefer it to be a semi-manual operation08:24
evI 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 lifting08:26
wgrantev: 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:35
evwgrant: it only holds the keys in cookies. In practice, I don't see then how it's different than a desktop application08:37
wgranteg. any writable token from an archive admin can root every Ubuntu machine in the world in fairly short order.08:37
evwgrant: would your suggestion then be to go back to creating a bot user for this sort of thing?08:39
wgrantev: I'm not quite sure.08:53
wgrantev: 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)08:54
evsure, but alas it does not and I have deadlines to meet :)09:11
ev(and other work items dependent on being able to associate an error with a bug number)09:12
lifelesswgrant: what do you mean by sensible - tightly controlled actions ?10:19
lifelessev: Why did you stop using a service account? they are the 'stock' answer we have for that sort of thing...10:20
cjwatsonwgrant: 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:27
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:31
cjwatsonIf 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:34
evlifeless: 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.10:39
wgrantlifeless: On any other OAuth service the tokens grant partial access depending on what the application requires.12:01
wgrantcjwatson: 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:01
wgrantcjwatson: It is probably a problem for a widely-accessed bug filing service to possess them.12:02
evwgrant, 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.14:47
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
lifelessev: what data will it ask the user for ?19:48
lifelessev: I suspect my answer is going to be 'use a bot and do the thing automatically with no button presses at all'19:49
evlifeless: 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 db19:49
lifelessev: so why does there need to be a button ?19:49
lifelesswgrant: I don't suppose you got the LEP together on friday afternoon after I EOD'd ?19:50
evyeah, 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 process19:50
evand it's really only needed for the things we'll fix19:50
evso if a crash happens once, creating a bug for it is just noise19:51
lifelessev: there is a button for that: 'invalid'19:52
evthe 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 rejected19:52
evlifeless: sure, but that requires human processing :)19:52
evSHA-1 hashes of the crash signature, that is. So you could avoid creating a bug report entirely.19:52
lifelessso the workflow is at-or-after fixing the issue, someone realises its on errors.ubuntu.com but didn't have a bug19:53
lifelessthey 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
lifelessif someone is working from errors.u.c, they might start with the button clicking19:54
evhalf 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 upload19:55
lifelessev: folk *will* fix things accidentally ;)19:55
evthat then goes into our facy bugs -> fixes UI19:55
lifelessev: whats the workflow when someone fixes it without telling the system in advance ?19:56
evlifeless: sure, and indeed that should do the right thing when faced with the scenario you've presented19:56
evit can do exactly that. Follow the bug to its parent and write that into the DB19:56
lifelessok19:57
evor 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 time19:59
lifelesscool19:59
lifelessok19:59
lifelessuhm20:00
lifelesswhat do you think folk would feel if:20:00
lifeless - the top10 frequency signatures automatically got bugs made20:00
lifeless - other signatures allow you to specify a bug # or request one get made20:01
lifelessev: btw, you can't safely use launchpadlib within a web service.20:01
lifelessev: you need to farm it out to a single threaded own-cache-owning worker.20:02
eveep20:02
evI think creating bugs for the top 10 frequency signatures automatically is reasonable20:02
lifelessoh, I forgot, its (privisionally) fixed.20:03
lifelessbug 45941820: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
lifelessI don't think its been released.20:03
evbeauty of web services - I don't have to wait for it to be20:03
lifelessthats in lazr.restful20:03
lifelesserm restfulclient20:04
lifelessso yes, you do ;)20:04
lifelessor you need to run your own tarball20:04
evwell I mean I can throw it into a PPA and add it to the dependencies package for webops20:04
evof course, it might be released faster than the PPA builds it :-P20:05
evah, but presumably that's blocked on bug 51311620:08
_mup_Bug #513116: launchpadlib is not thread-safe <lp-foundations> <oem-services> <Launchpad itself:Triaged> <launchpadlib :Triaged> < https://launchpad.net/bugs/513116 >20:08
lifelessreleasing lazr.restfulclient blocked? no. But using launchpadlib in a web server - yes, thats blocked ;)20:10
lifelessev: if I may make a suggestion20:11
lifelessev: for make-a-bug, use a parameterised link directly to launchpad, and the user can go through the filing form themselves.20:11
lifelessev: for automatically-make-it do it in celery/rabbit consumer/backend script/whatever20:12
lifelessev: its not quite as nice, but it will be a lot faster to put together, and you can iterate later20:13
evlifeless: 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
lifelessev: 'forever'20:14
evhahaha, oh dear20:14
evwell, using celery isn't a bad thing20:15
lifelesssure :)20:15
lifelessev: anyhow, does that give you enough to go on?20:20
evlifeless: it surely gives me enough to keep me busy for a while :)20:20
lifelessev: was my reply to the just-in-time thread sane ?20:20
evlifeless: the librarian one?20:20
lifelessyes20:21
evyes, and thank you for following up to that20:21
lifelessmy pleasure20:21
lifelessit had slipped past me for a bit20:21
evand 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:23
lifelessyeah, it makes quie a difference to the incremental overheads :)20:24

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!