[12:23] <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:24] <benji> frankban: sure, I'll look at it right now
[12:24] <frankban> benji: thanks
[12:28] <frankban> benji: Gary just did it now
[12:28] <benji> heh, ok
[15:20] <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:21] <frankban> thanks
[15:21] <benji> frankban: +1'd
[15:22] <frankban> benji: thanks, what am I supposed to do now? add a :shipit: comment?
[15:23] <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:25] <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:27] <frankban> benji: and my understanding is that when you review a branch ":+1:" is the new LGTM
[15:27] <benji> frankban: yep
[15:29] <frankban> ok, sorry we did not choose :smile_cat:
[15:44] <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:45] <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:58] <bac> frankban, benji: we having a call today?
[16:01]  * benji needs a reboot... aparently.
[16:02] <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:03] <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!
[17:45] <bac> ah, i love it when an upgrade fails with an unhelpful error and leaves the computer in an unknown state
[17:57] <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:58] <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:59] <hazmat> fwiw
[17:59] <benji> ok (this was specifically for the '- ["foo:bar", "baz:bar"]' style)
[20:50] <benji> I have a charmworld branch up for review: https://codereview.appspot.com/54560044
[21:00] <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:01] <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:02] <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:03] <abentley> jcsackett: Not something I've seen before.
[21:03] <jcsackett> abentley: dig, thanks.
[21:04] <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:09] <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:10] <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:11] <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:12] <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:13] <jcsackett> abentley: yes. that is the thing triggering the bad here. let me see if i can grab the queue traceback.
[21:16] <jcsackett> abentley: actual issue i was investigating https://pastebin.canonical.com/103261/
[21:16] <jcsackett> same exception, very different traceback.
[21:18] <abentley> jcsackett: Gotcha.
[21:18] <jcsackett> so what we've learned is we're having myriad sorting issues. :-P
[21:19] <abentley> jcsackett: Not sure whether it's strictly necessary for the lp version to be sorted by branch_spec.
[21:20] <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:21] <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.
[22:00] <huwshimi> Morning