[09:56] Could I have a review of https://code.launchpad.net/~cjwatson/lp-signing/+git/lp-signing/+merge/382431 (Run migrations in charm), please? [10:00] cjwatson: you have migrations happening before service.configured, is that the right order? [10:01] tomwardill: I think so - doesn't seem like a good idea to claim that the app is up before its DB schema is up to date [10:01] fair [10:01] have a +1 :) [10:03] (In fact, gunicorn starts on service.configured, so we definitely need to avoid doing that early.) [10:03] There is a certain amount of puzzle-box programming here to figure out exactly how to avoid tickling the OLS layers in the wrong way. [10:03] Thanks [10:05] * tomwardill fetches more coffee [10:58] do we want users to be able to create credenti'als with the same url and username? [10:58] I'm leaning towards we should check for that [11:00] It seems likely to be confusing [11:00] * tomwardill adds the check [11:00] but first, lunch [11:01] Ah that's right, didn't add a DB constraint because we weren't really sure enough of what form creds would take I think [11:44] Yeah, still not sure. The first set is obviously going to be username and password, but tokens are a possibility later. [11:44] Doing code checks for it makes the most sense, as we’ll need to change the push code to handle anything other than None and username/password [11:46] Not to mention the UI. [11:46] Oh yes, that too. [12:23] https://code.launchpad.net/~cjwatson/lp-signing/+git/lp-signing/+merge/382581 brown-paper-bag fix to DB setup, please review [12:34] cjwatson: +1 [14:30] cjwatson: do we have any precedence for a 'createOrExisting' type method? [14:31] I'm thinking Registry Credentials could use that [14:31] maybe get_or_create is a better description [14:37] tomwardill: Yeah, there are various [14:37] tomwardill: Several getOrCreateFoo [14:37] tomwardill: ensureFoo is also an option [14:38] ah, excellent [14:38] I shall try some variant of that [15:42] * tomwardill blergs at the web service [15:44] getting a 401 when I try to call my new method, when I am definitely the owner [15:45] Is there anything on the response's body? [15:45] "(, 'createPushRule', 'launchpad.Edit')" [15:47] strange... did you try `user.isOwner(the_oci_recipe_object)`, just to make sure? [15:47] I usually find that some bit of ownership is not what I think it is ... [15:47] is there a way to debug this? [15:48] On security.py, put a breaking point at EditOCIRecipe.checkAuthenticated [15:49] Yep [15:49] Alternatively, breakpoint on zope.publisher.publish.mapply is a bigger hammer if you need it [15:49] That should be shortly before the traversed-to method is entered [15:49] oh, maybe I'm doing a silly [15:50] (But EditOCIRecipe.checkAuthenticated is an easier place to start, probably) [15:50] narrator: he was doing a silly. [15:50] (forgot the owner= on factory.makeOCIRecipe) [15:50] 16:47 I usually find that some bit of ownership is not what I think it is ... [15:50] :-) [15:51] hahaha! Been there, done that... [15:51] NoCanonicalUrl: No url for ah, yes [15:51] that [15:51] pappacena: Could you have a quick look at https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/382592 ? [15:52] * pappacena sure! [15:52] Should fix an OOPS I hit on dogfood [15:52] Tom, URL tag on zcml... export the new entity on webservice.py... [15:53] Ahm... I didn't realise the signing process uses a different db user. Thanks for the MP, cjwatson [15:55] Easy to miss [16:06] pappacena: Did you notice http://lpbuildbot.canonical.com/builders/lp-devel-xenial/builds/1192/steps/shell_9/logs/summary ? [16:06] No... let me check [16:07] and/or do you need help debugging it? [16:08] Ugh, passes for me locally [16:08] I'll try to reproduce... but I don't recognize those tests... [16:09] uhm... [16:09] there was a timeout trying to start rabbitmq at the begining... could that be the cause? [16:10] pappacena: Ah, the patch that triggered this was just adding DB tables, so buildbot is probably unfairly blaming you [16:10] It's possible [16:10] Let me force build it again [16:10] I've just retried, sorry for the noise [16:10] No problem :) [16:21] testtools.matchers._impl.MismatchError: 200 != 404: Object: , name: u'string:distribution-100004' [16:21] you're not wrong there testtools, you're not wrong [16:22] That string: is slightly suspicious [16:22] Feels like a buggy [16:22] yeah, that would make sense [16:23] I'm failing to define the correct url for a pushrule, apparently [16:38] any ideas why "path_expression="string:+pushrule/${id}" is producing: 'http://api.launchpad.test/devel/~person-name-100000/distribution-100004/+oci/oci-project-name-100017/+recipe/oci-recipe-name-100018/+pushrule/None' [16:38] the None there isn't exactly right... [16:41] Strange. Is it really commited to database? Did you check if the OCIPushRule object actually has an ID at that point? [16:42] ids are typically serials which are generated by the DB in the process of adding the row, so you may need to flush after adding the object to the store in order to get the id back [16:42] (commit would do it too but is overkill) [16:50] Another small fix found while QAing the signing service: https://code.launchpad.net/~cjwatson/lp-signing/+git/lp-signing/+merge/382598 [16:50] I'll check [16:51] okay, that fixed my id, now to work out why I'm getting a 404 :) [16:56] New @stepthrough method on OCIRecipeNavigation ? [17:02] yep, that's the one. Ta pappacena :) [17:02] * pappacena Good! :) [17:14] Total: 217 tests, 0 failures, 0 errors, 0 skipped in 2 minutes 55.683 seconds. [17:14] well, that'll do. Cleaning up the mess I've made along the way is a job for FutureTom [17:14] * tomwardill -> EOD :) [19:52] https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/382606 (Add UI for editing Distribution.oci_project_admin) [19:59] * pappacena I'll check [20:02] I've done a bunch of QA and intend to do a rollout tonight; we need to get it out this week, but rollouts for the next few days will have to be extra-careful to avoid disrupting the Ubuntu release, so it has to be now [20:03] (Not ideal timing, but there you go) [20:03] Shout if you know of anything wrong [20:03] Ok... let me know if something doesn't work properly... [20:07] Actually ... bother, I just realised that the comment about bug contacts in https://bugs.launchpad.net/launchpad/+bug/117752 still stands [20:07] Bug #117752: Any logged in user can delete any attachments [20:08] Which we discussed briefly in the MP, but I'd missed that comment about retracers deleting attachments [20:08] retracers? [20:10] Ubuntu has an automatic crash reporting system which in some cases creates bugs with core dumps attached, but those have to be private since they often contain lots of confidential information; there's a service that goes through core dumps attached to bugs in this way and extracts tracebacks from them, then deletes the core dumps, which makes it less of a privacy minefield [20:10] But the "deletes the core dumps" bit is kind of crucial [20:11] Sorry, I should have thought of that wrinkle earlier [20:11] Ahh... what permission should we use to allow them to delete too? [20:11] bug_supervisor, but it involves looking at bug tasks [20:11] Because that's on the pillar [20:12] But then we have to take more care about performance because bugs might have lots of bug tasks [20:13] EditBug._hasAnyRole is similar and would probably do [20:13] Let me think for a bit about whether we can get away with taking that slow approach [20:14] Ok... [20:16] pappacena: I think we can. Mind if I take this? We're in a bit of a rush and I think I can do it faster than I can explain it :) [20:17] Sure, no problem! :-) [20:35] pappacena: https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/382608 [20:39] * pappacena checking [20:49] Thanks, landing [20:54] pappacena: Before I forget - nice work on the lp-signing integration so far. Once I fixed all the things that were essentially my fault (charm bugs, incorrect firewall rule, missing escaping in openssl's command line), it all seems to work just fine. [20:55] Though I don't think we should actually attempt to enable it until after the Ubuntu release, even if we have a production environment by then :-) [21:06] Thanks, cjwatson! And actually, thanks for all the reviews and the work on the infrastructure... my part was actually quite small compared to this. [21:06] And I agree to play it safe and wait for Ubuntu release before we enable this in production.