/srv/irclogs.ubuntu.com/2014/01/20/#juju-gui.txt

frankbanhey 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/5456004312:23
benjifrankban: sure, I'll look at it right now12:24
frankbanbenji: thanks12:24
frankbanbenji: Gary just did it now12:28
benjiheh, ok12:28
frankbanbenji: could you please review this very simple branch? https://github.com/juju/juju-gui/pull/78 (I am just trying git)15:20
benjifrankban: sure15:20
frankbanthanks15:21
benjifrankban: +1'd15:21
frankbanbenji: thanks, what am I supposed to do now? add a :shipit: comment?15:22
benjifrankban: yep15:23
frankbanbenji: so, the procedure is: 1) make a pull request, 2) wait for jenkins 3) ask for a review and 4) :shipit:, correct?15:23
bacfrankban: that is my understanding15:25
benjifrankban: yep, with the exception of "wait"; I've never bothered to wait nor heard that that is what we want 15:25
frankbanbenji: ack, cool15:25
frankbanbenji: and my understanding is that when you review a branch ":+1:" is the new LGTM15:27
benjifrankban: yep15:27
frankbanok, 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 like15:44
benjirick_h_: is the wait before review or parallel with it?15:44
frankbanrick_h_: but you don't have to wait before asking for reviews, right?15:44
rick_h_for small changes/doc changes/ meh15:45
rick_h_benji: parallel15:45
rick_h_benji: frankban oh yea not at all a wait for review15:45
rick_h_just a wait until hitting :shipit:15:45
frankbanrick_h_: ack15:45
benjisounds good15:45
bacfrankban, benji: we having a call today?15:58
* benji needs a reboot... aparently.16:01
bacfrankban: meeting if you have anything to say.  T+216:02
bacwere we a space shuttle we'd be nearing first stage separation16:02
bacor SRB detachment16:02
bacor something16:02
frankbanbac: we can skip it for today, I sent an email for everything I did earlier16:02
frankbanbac: re: quickstart 1.016:03
bacfrankban: ok16:03
bacwell benji is joining...if he gets sound working16:03
frankbanbac: ok joining16:03
bacfrankban: no, no pressure!  :)16:03
baccongrats on quickstart 1.0 though!16:03
bacah, i love it when an upgrade fails with an unhelpful error and leaves the computer in an unknown state17:45
benjijujugui: 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
hazmatbenji, yes they are ordered17:58
benjihazmat: great!  thanks17:58
hazmatbenji, there's an older syntax that's also supported that does relations as dict entries with weight ordering.17:58
hazmatfwiw17:59
benjiok (this was specifically for the '- ["foo:bar", "baz:bar"]' style)17:59
benjiI have a charmworld branch up for review: https://codereview.appspot.com/5456004420:50
jcsackettbenji, 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
bacjcsackett: looking too21:01
jcsacketti 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
jcsackettabentley: 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
abentleyjcsackett: sure.21:02
jcsackettthe 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 staging21:02
abentleyjcsackett: Not something I've seen before.21:03
jcsackettabentley: dig, thanks.21:03
jcsacketthm. 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
abentleyjcsackett: 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
abentleysorry, store_data.revision.21:09
abentleyand, I guess, owner, series, name.21:09
jcsackettabentley: 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_spec21:10
jcsackettit is *very* possible, looking at this one as well, that we need more than one index for charms.21:11
abentleyjcsackett: Ah.21:11
abentleyjcsackett: 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
jcsackettabentley: yes. that is the thing triggering the bad here. let me see if i can grab the queue traceback.21:13
jcsackettabentley: actual issue i was investigating https://pastebin.canonical.com/103261/21:16
jcsackettsame exception, very different traceback.21:16
abentleyjcsackett: Gotcha.21:18
jcsackettso what we've learned is we're having myriad sorting issues. :-P21:18
abentleyjcsackett: Not sure whether it's strictly necessary for the lp version to be sorted by branch_spec.21:19
abentleyjcsackett: I think it's two reflections of the same issue: the charms collection has gotten big enough that it needs indices now.21:20
jcsackettyeah.21:20
abentleyjcsackett: 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 nods21:21
jcsackettyeah, so we can probably skip branch_spec and just not sort that query.21:21
huwshimiMorning22:00

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!