[12:23] 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:24] frankban: sure, I'll look at it right now [12:24] benji: thanks [12:28] benji: Gary just did it now [12:28] heh, ok [15:20] benji: could you please review this very simple branch? https://github.com/juju/juju-gui/pull/78 (I am just trying git) [15:20] frankban: sure [15:21] thanks [15:21] frankban: +1'd [15:22] benji: thanks, what am I supposed to do now? add a :shipit: comment? [15:23] frankban: yep [15:23] benji: so, the procedure is: 1) make a pull request, 2) wait for jenkins 3) ask for a review and 4) :shipit:, correct? [15:25] frankban: that is my understanding [15:25] frankban: yep, with the exception of "wait"; I've never bothered to wait nor heard that that is what we want [15:25] benji: ack, cool [15:27] benji: and my understanding is that when you review a branch ":+1:" is the new LGTM [15:27] frankban: yep [15:29] ok, sorry we did not choose :smile_cat: [15:44] 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] rick_h_: is the wait before review or parallel with it? [15:44] rick_h_: but you don't have to wait before asking for reviews, right? [15:45] for small changes/doc changes/ meh [15:45] benji: parallel [15:45] benji: frankban oh yea not at all a wait for review [15:45] just a wait until hitting :shipit: [15:45] rick_h_: ack [15:45] sounds good [15:58] frankban, benji: we having a call today? [16:01] * benji needs a reboot... aparently. [16:02] frankban: meeting if you have anything to say. T+2 [16:02] were we a space shuttle we'd be nearing first stage separation [16:02] or SRB detachment [16:02] or something [16:02] bac: we can skip it for today, I sent an email for everything I did earlier [16:03] bac: re: quickstart 1.0 [16:03] frankban: ok [16:03] well benji is joining...if he gets sound working [16:03] bac: ok joining [16:03] frankban: no, no pressure! :) [16:03] congrats on quickstart 1.0 though! [17:45] ah, i love it when an upgrade fails with an unhelpful error and leaves the computer in an unknown state [17:57] 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 [17:58] benji, yes they are ordered [17:58] hazmat: great! thanks [17:58] benji, there's an older syntax that's also supported that does relations as dict entries with weight ordering. [17:59] fwiw [17:59] ok (this was specifically for the '- ["foo:bar", "baz:bar"]' style) [20:50] I have a charmworld branch up for review: https://codereview.appspot.com/54560044 [21:00] 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:01] jcsackett: looking too [21:01] 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] 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:02] jcsackett: sure. [21:02] 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] +1 on trying it on staging [21:03] jcsackett: Not something I've seen before. [21:03] abentley: dig, thanks. [21:04] 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:09] 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] sorry, store_data.revision. [21:09] and, I guess, owner, series, name. [21:10] 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:11] it is *very* possible, looking at this one as well, that we need more than one index for charms. [21:11] jcsackett: Ah. [21:12] 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:13] abentley: yes. that is the thing triggering the bad here. let me see if i can grab the queue traceback. [21:16] abentley: actual issue i was investigating https://pastebin.canonical.com/103261/ [21:16] same exception, very different traceback. [21:18] jcsackett: Gotcha. [21:18] so what we've learned is we're having myriad sorting issues. :-P [21:19] jcsackett: Not sure whether it's strictly necessary for the lp version to be sorted by branch_spec. [21:20] 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] yeah. [21:21] 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] yeah, so we can probably skip branch_spec and just not sort that query. [22:00] Morning