frankban | hey benji: welcome back! if you are really here, and if you have time, could you please review a quick branch required to fix the quickstart release? https://codereview.appspot.com/54560043 | 12:23 |
---|---|---|
benji | frankban: sure, I'll look at it right now | 12:24 |
frankban | benji: thanks | 12:24 |
frankban | benji: Gary just did it now | 12:28 |
benji | heh, ok | 12:28 |
frankban | benji: could you please review this very simple branch? https://github.com/juju/juju-gui/pull/78 (I am just trying git) | 15:20 |
benji | frankban: sure | 15:20 |
frankban | thanks | 15:21 |
benji | frankban: +1'd | 15:21 |
frankban | benji: thanks, what am I supposed to do now? add a :shipit: comment? | 15:22 |
benji | frankban: yep | 15:23 |
frankban | benji: so, the procedure is: 1) make a pull request, 2) wait for jenkins 3) ask for a review and 4) :shipit:, correct? | 15:23 |
bac | frankban: that is my understanding | 15:25 |
benji | frankban: yep, with the exception of "wait"; I've never bothered to wait nor heard that that is what we want | 15:25 |
frankban | benji: ack, cool | 15:25 |
frankban | benji: and my understanding is that when you review a branch ":+1:" is the new LGTM | 15:27 |
benji | frankban: yep | 15:27 |
frankban | ok, sorry we did not choose :smile_cat: | 15:29 |
rick_h_ | benji: frankban the wait is in the instructions in the HACKING doc. The idea to wait is so that you don't end up taking up the 20min time for a landing attempt only to hit a known test failure, lint failure, etc. Especially since both the pull request check and the landing will test saucelabs with IE and the like | 15:44 |
benji | rick_h_: is the wait before review or parallel with it? | 15:44 |
frankban | rick_h_: but you don't have to wait before asking for reviews, right? | 15:44 |
rick_h_ | for small changes/doc changes/ meh | 15:45 |
rick_h_ | benji: parallel | 15:45 |
rick_h_ | benji: frankban oh yea not at all a wait for review | 15:45 |
rick_h_ | just a wait until hitting :shipit: | 15:45 |
frankban | rick_h_: ack | 15:45 |
benji | sounds good | 15:45 |
bac | frankban, benji: we having a call today? | 15:58 |
* benji needs a reboot... aparently. | 16:01 | |
bac | frankban: meeting if you have anything to say. T+2 | 16:02 |
bac | were we a space shuttle we'd be nearing first stage separation | 16:02 |
bac | or SRB detachment | 16:02 |
bac | or something | 16:02 |
frankban | bac: we can skip it for today, I sent an email for everything I did earlier | 16:02 |
frankban | bac: re: quickstart 1.0 | 16:03 |
bac | frankban: ok | 16:03 |
bac | well benji is joining...if he gets sound working | 16:03 |
frankban | bac: ok joining | 16:03 |
bac | frankban: no, no pressure! :) | 16:03 |
bac | congrats on quickstart 1.0 though! | 16:03 |
bac | ah, i love it when an upgrade fails with an unhelpful error and leaves the computer in an unknown state | 17:45 |
benji | jujugui: does anyone know if the order of relations in a deployer file are meant to be taken as ordered? Bug 1263120 boils down to the charmworld proof mechanism enforcing (requires, provides) ordering so specifying a relation as (provides, requires) is flagged as incompatible. | 17:57 |
_mup_ | Bug #1263120: self related services in a bundle fail proof <charmworld:Triaged> <https://launchpad.net/bugs/1263120> | 17:57 |
hazmat | benji, yes they are ordered | 17:58 |
benji | hazmat: great! thanks | 17:58 |
hazmat | benji, there's an older syntax that's also supported that does relations as dict entries with weight ordering. | 17:58 |
hazmat | fwiw | 17:59 |
benji | ok (this was specifically for the '- ["foo:bar", "baz:bar"]' style) | 17:59 |
benji | I have a charmworld branch up for review: https://codereview.appspot.com/54560044 | 20:50 |
jcsackett | benji, bac (and other charmworld folks): i am seeing on staging that queueing is not completing because a query is too large to complete a sort without an index. https://pastebin.canonical.com/103258/ | 21:00 |
* benji looks at paste. | 21:00 | |
bac | jcsackett: looking too | 21:01 |
jcsackett | i believe an index on branch_spec can solve this. any objections to my building one on staging? it will likely affect staging performance for a bit. | 21:01 |
jcsackett | abentley: if you're around, can you take a look at traceback and weigh in as well? as i recall you did quite a bit with mongo stuff on charmworld ^ | 21:01 |
abentley | jcsackett: sure. | 21:02 |
jcsackett | the other solution i can think of is restructuring db_charms so that it doesn't sort in the query, but creates a list and sorts that...it may be a *lot* to keep in memory in the python process though. | 21:02 |
benji | +1 on trying it on staging | 21:02 |
abentley | jcsackett: Not something I've seen before. | 21:03 |
jcsackett | abentley: dig, thanks. | 21:03 |
jcsackett | hm. actually, i just realized that traceback is in a different part of the application...however it reliably occurs on queueing, so that's a reasonable test case. | 21:04 |
abentley | jcsackett: Why do you think branch_spec is the key? I would have thought the charm.revision, since that's what it's sorting by. | 21:09 |
abentley | sorry, store_data.revision. | 21:09 |
abentley | and, I guess, owner, series, name. | 21:09 |
jcsackett | abentley: i grabbed a different traceback from the log to paste than the one i was initially looking at (i had closed the terminal, then realized an example might make more sense for people). the traceback i saw, on queueing, is sorting on branch_spec | 21:10 |
jcsackett | it is *very* possible, looking at this one as well, that we need more than one index for charms. | 21:11 |
abentley | jcsackett: Ah. | 21:11 |
abentley | jcsackett: Yes, but also find_charms(all_revisions=False) was only meant to be a band-aid. Things that want the unversioned charm should hit elasticsearch. | 21:12 |
jcsackett | abentley: yes. that is the thing triggering the bad here. let me see if i can grab the queue traceback. | 21:13 |
jcsackett | abentley: actual issue i was investigating https://pastebin.canonical.com/103261/ | 21:16 |
jcsackett | same exception, very different traceback. | 21:16 |
abentley | jcsackett: Gotcha. | 21:18 |
jcsackett | so what we've learned is we're having myriad sorting issues. :-P | 21:18 |
abentley | jcsackett: Not sure whether it's strictly necessary for the lp version to be sorted by branch_spec. | 21:19 |
abentley | jcsackett: I think it's two reflections of the same issue: the charms collection has gotten big enough that it needs indices now. | 21:20 |
jcsackett | yeah. | 21:20 |
abentley | jcsackett: Pretty sure that the sorting by branch_spec isn't relevant to usage, since all_charms shoves it into a dict anyway. | 21:21 |
* jcsackett nods | 21:21 | |
jcsackett | yeah, so we can probably skip branch_spec and just not sort that query. | 21:21 |
huwshimi | Morning | 22:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!