| === anthonyf is now known as Guest70961 | ||
| lifeless | wgrant: what blew up? | 01:22 |
|---|---|---|
| wgrant | lifeless: MySQL got very attached to keystone's token table and wouldn't let anyone else have a look. | 01:22 |
| lifeless | eep | 01:22 |
| lifeless | there's a incremental cleaner spamaps wrote | 01:22 |
| lifeless | its pretty much the only safe way to clear stuff in that table | 01:23 |
| wgrant | lifeless: This was a more restricted version of the query from "keystone-manage token_flush" | 01:24 |
| wgrant | (though that query is itself pretty silly) | 01:24 |
| lifeless | oh no | 01:29 |
| lifeless | thats not the safe way | 01:29 |
| wgrant | It's clearly not safe, but it shouldn't failed in quite the way it did. | 01:31 |
| lifeless | wgrant: https://github.com/openstack/tripleo-image-elements/blob/master/elements/keystone/cleanup-keystone-tokens.sh | 01:32 |
| wgrant | lifeless: Ah yes, why didn't I think to look there :) | 01:32 |
| lifeless | wgrant: I know, I know | 01:32 |
| lifeless | there's a story, of course | 01:32 |
| lifeless | wgrant: well, I'd need to see the query you used (so I can show it to spamaps :P)) to see if what happened is expected.. but I've seen that pathology before | 01:33 |
| wgrant | hahahahah | 01:33 |
| wgrant | "Also, because the keystone tokens are somewhat random 64 byte strings, there will be gaps in the InnoDB key storage. In order to preserve transactional integrity while deleting these rows, InnoDB has to lock these gaps. So new tokens that fit into these gaps will have to wait for the entire delete to finish to be inserted." | 01:33 |
| wgrant | srsly? | 01:33 |
| lifeless | yes | 01:35 |
| lifeless | its how mysql handles new keys in gaps in the index | 01:36 |
| lifeless | to deal with range queries being invalidated | 01:36 |
| lifeless | I forget the details on postgresql's handling of that (which IIRC happened in 9.0?) | 01:36 |
| wgrant | Right, the new SERIALIZABLE transactions do range locking. | 01:36 |
| wgrant | But not like that... | 01:37 |
| wgrant | (unless something was actually doing range queries on the token value, which seems unlikely) | 01:43 |
| blr | wgrant: will need to have a review/landing for product-setbranch first, but would you mind a quick sanity check on https://code.launchpad.net/~blr/launchpad/project-meta-go-import/+merge/262550 please? | 02:56 |
| wgrant | blr: Should use vhost.mainsite.hostname rather than launchpad.non_restricted_hostname. secure_codebrowse_root also isn't usable here (you can't branch from it), so you want branch.bzr_identity to get an lp: URL instead. | 03:03 |
| blr | wgrant: I'm not sure the lp: prefix will work in this context will it? | 03:04 |
| wgrant | We also can't expose a git repository for productseries. | 03:04 |
| wgrant | blr: It depends how go get parses it. | 03:04 |
| wgrant | if it gives it to bzr or bzrlib, it will handle lp: fine. | 03:04 |
| wgrant | But it may be excessively pedantic. | 03:04 |
| blr | mwhudson: any idea there? | 03:04 |
| blr | wgrant: err true, it only needs the bzr case for product series.. | 03:06 |
| wgrant | blr: If the productseries case isn't already supported by the manual launchpad.net bits of go get, we shouldn't support it either. | 03:07 |
| mwhudson | there is supoprt in the go tool for lp:product/series | 03:10 |
| mwhudson | (unfortunately) | 03:10 |
| mwhudson | i don't entirely understand what it is doing :-) | 03:10 |
| blr | mwhudson: would you be able to do a bit of digging to see if the remote import path will support lp:product/series? | 03:12 |
| mwhudson | blr: what do you mean, exactly? | 03:12 |
| mwhudson | i'm happy to dig, sure | 03:12 |
| mwhudson | although, arg, regex | 03:13 |
| blr | can I render `lp:product/series' rather than the http uri | 03:13 |
| mwhudson | re: `^(?P<root>launchpad\.net/((?P<project>[A-Za-z0-9_.\-]+)(?P<series>/[A-Za-z0-9_.\-]+)?|~[A-Za-z0-9_.\-]+/(\+junk|[A-Za-z0-9_.\-]+)/[A-Za-z0-9_.\-]+))(/[A-Za-z0-9_.\-]+)*$`, | 03:13 |
| mwhudson | oh i see | 03:13 |
| blr | e.g. <meta name="go-import" content="launchpad.net/product/series bzr lp:product/series"> | 03:13 |
| mwhudson | magic 8 ball says ask again later | 03:15 |
| blr | mwhudson: fair enough | 03:15 |
| mwhudson | seriously, not quite sure, will need to stare a bit harder at this | 03:15 |
| mwhudson | i think it will need to be lp:// to avoid scheme pedantry :) | 03:19 |
| mwhudson | otherwise ... i think it will probably work | 03:19 |
| mwhudson | oh hrm, maybe not? | 03:21 |
| mwhudson | blr: if you just make it say https://launchpad.net/product/series that matches what the go tool will do today | 03:25 |
| mwhudson | and https://launchpad.net/product on the top level page | 03:25 |
| mwhudson | i think | 03:25 |
| blr | mwhudson: ok thanks | 03:40 |
| blr | wgrant: in that case, is secure_codebrowse_root appropriate? | 03:41 |
| blr | or is there an https equivalent of bzr_identity | 03:41 |
| wgrant | hum, it relies on the webapp redirect behaviour? we should probably not. | 03:53 |
| mwhudson | currently it does | 04:12 |
| mwhudson | agree that's a bit daft and it would be nice to not do that i guess | 04:12 |
| === heroux_ is now known as heroux | ||
| === mthaddon` is now known as mthaddon | ||
| cjwatson | wgrant: Thanks for the testfix, BTW | 10:36 |
| === anthonyf is now known as Guest35024 | ||
| cjwatson | wgrant: Did you get a chance to look over https://code.launchpad.net/~cjwatson/launchpad/git-repository-ui-edit-target/+merge/261232 again, or should I just go ahead and land that? | 11:48 |
| wgrant | cjwatson: Ah, sorry, wasn't here today. Will have a quick look. | 11:51 |
| * cjwatson wonders what's up with https://code.launchpad.net/~wgrant/launchpad/git-import-stable and friends. 12-hour scans, it seems to find revisions but they aren't visible on bazaar.launchpad.net, even via sftp | 11:53 | |
| wgrant | cjwatson: They are not scans. | 11:53 |
| wgrant | Their respective imports are incomplete, but continue 30,000 revisions at a time. | 11:54 |
| wgrant | That is the cause of the grey rather than the green tick. | 11:54 |
| wgrant | cjwatson: No big issues with the branch. Feel free to land it. | 11:56 |
| cjwatson | imports> oh, right | 11:57 |
| cjwatson | Thanks. | 11:57 |
| wgrant | The scans should succeed after a retry or two, once the import is complete. | 11:58 |
| wgrant | I manually did an incremental scan to get the initial one in. | 11:59 |
| cjwatson | Explains why I couldn't find anything in ackee's bzrsyncd logs, anyway. | 11:59 |
| cjwatson | Incremental scan? | 11:59 |
| wgrant | Inserting the 130,000 Revisions, RevisionParents, etc. on top of the 130,000 BranchRevisions is simply too much. | 12:00 |
| wgrant | So for initial scans of new big branches we have to do it gradually: push them a couple of thousand revisions at a time, so the Revisions aren't all created in one hit which times out. | 12:00 |
| wgrant | Similar to the way imports work, except in smaller batches and manually. | 12:01 |
| === anthonyf is now known as Guest16072 | ||
| === anthonyf is now known as Guest26733 | ||
| === elmo_ is now known as elmo | ||
| blr | morning | 20:47 |
| === mup_ is now known as mup | ||
| blr | wgrant: working on GitRepositoryVocabularyOnProduct, have mostly copied the existing bzr class, but making some sense of it I think. | 22:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!