[01:12] hey huwshimi [01:49] huwshimi: actually could you do me a favor today please? There's one card in there "The complete changelog doesn't indicate" [01:49] huwshimi: could you look at that card in MV tonight? It's a small counting one that I think would be a nice to have and small to do [01:52] rick_h_: Yep np [01:52] huwshimi: ty much [01:52] no problems at all === urulama-afk is now known as urulama [10:57] morning [10:58] rick_h_: morning [10:59] how goes fabrice? [10:59] fabrice: any luck on the charm front? [11:00] rick_h_: I have the scripts wrapped but I am still trying to get it running under a vm ubuntu server utopic which launch lxc utopic [11:00] rick_h_: my changes are at least working on trusty [11:01] rick_h_: I would love to have an apt cache of some sort :) [11:03] rick_h_: this will be ready sometimes this afternoon after the test [11:03] but first lunch === fabrice is now known as fabrice|lunch [11:07] fabrice|lunch: enjoy === fabrice|lunch is now known as fabrice [14:22] quiet in here! [14:22] ssshhhh [14:25] :P [14:39] rick_h_: i left the "remove mv flag" card in coding--should i park that there and create a new card for each bit i put up for review, or keep creating new cards in coding and move them along? [14:40] jcsackett: park it, there's WIP room [14:40] rick_h_: cool. [14:40] just make sure you get reviews as needed [14:40] jcsackett: are there a couple coming up? [14:40] jcsackett: I got the first one [14:44] rick_h_: i saw, and replied. [14:46] jcsackett: rgr, shipping it now. [14:46] rick_h_: well damn. good thing i QAed before proposing. :p [14:46] I'll call it trivial. :) [14:47] rick_h_: yeah, but you shipit'ed before i actually pushed my update, since i was going to wait on second review. :p [14:47] i'll fold it into the next branch. [14:48] lol [14:54] jujugui call in 7 please kanban [14:55] hrm. i miss bzr/launchpad support for pipes and prerequisite branches in prs. [15:01] mhilton: standup time [15:18] kadams54: ping got a sec? [15:18] rick_h_: sure === fabrice is now known as fabrice|family [15:42] Makyo: can you email a link to your raw video to sally and myself please [15:42] guihelp: I'm ready for a pre-impl call on my card. Somehow, when you delete a relation, the aggregatedStatus attribute on a *different* relationship (or no relationship at all) is getting set to "pending-healthy". [15:54] that's odd [15:54] kadams54: do you have any idea where? [15:54] like have you traced the delete code? [15:55] Yes… it doesn't appear to be happening in the delete code. [15:55] you sure you have the simulator off? [15:55] :) [15:55] This is in EC2 [15:55] Rather, it happens as part of the topo update that gets called from _dbChangedHandler in app.js [15:56] Which is triggered by the delete [15:58] Things go off the tracks here: https://github.com/juju/juju-gui/blob/develop/app/views/topology/relation.js#L410 [15:59] So relation.aggregatedStatus is set to "pending-healthy" for the incorrect relation when the class gets set. But I'm not sure where/when aggregatedStatus is being changed to the wrong value. [16:00] kadams54: you can attach a change event handler to the attribute [16:00] put a debugger in the callback and you'll get a good async traceback [16:01] Yeah… since I'm debugging in a real env I'm trying to do all the digging before changing code. [16:01] ahh right right [16:01] But I suppose I could switch back to sandbox since I've confirmed this happens in both places. I'm just leary given all the sandbox-only bugs we've found. [16:02] good news is that aggregatedStatus is only touched in 5 places in the cod3e [16:03] agregatedStatus has a complex getter [16:03] I'd probably start in there [16:09] Yeah, I'm looking in there. Right now it seems like relation.pending is still set to false on the relation I just deleted. [16:11] Strike that… the pending attribute doesn't come into play here. Rather, the deleted attribute is what's important, and that is set incorrectly (to true) on the wrong relation. [16:11] Time to do more digging to find out who's setting that… [16:15] jujugui: can i get 2 reviews and a QA on https://github.com/juju/juju-gui/pull/576 ? it's mostly deletes. [16:15] yeah that;s odd [16:15] jcsackett: sure [16:16] jcsackett: Sure. My head is starting to hurt on my card anyhow :-) [16:17] thanks, hatch, kadams54. [16:19] jcsackett: sad to see all this work go [16:19] :) [16:21] :p [16:23] although the git diff is wako [16:32] jcsackett: just one comment could you investigate it plz [16:33] hatch: it's used in topology/service.js [16:34] in a tangled mess with relations and stuff. [16:34] it may very well be able to go, but it requires research outside of the scope of removing the MV flag. [16:35] one has to suss out the whole topology set. [16:42] jcsackett: ahh ok that's what I was worried about thanks [16:42] could you create a bug around that so we know to go revisit it at a later time? [16:42] and +1 === urulama is now known as urulama-afk [16:51] Makyo: well I tried :) maybe one of these days we'll get named params in js [16:52] It'd be nice! [16:56] oh well - I always have Dart [16:57] hmm this conflict UI stuff might be a little more work than I had thought [16:58] jujugui is there anywhere else in the app that we use the conflict resolution besides in the config? I can't find anything so just confirming [17:00] hatch: no, that's it [17:01] ok - this would probably lend itself well to something like react now with a conflict ui layer on top [17:01] this databinding is....complex [17:02] :) [17:10] lunching [17:15] jujugui anyone want to sit and listen to me reason about my implementation for the new conflict resolution fixes? [17:15] hatch: otp for the next hour but happy to after that [17:17] ok I'm going to start hacking on this and then whenever you have a moment ping me and I'll run through it [17:18] hatch: rgr [17:32] rick_h_: timeoff request posted [17:32] jus a piddly little thing [17:32] :) [17:53] jujugui would like another quick look at https://github.com/juju/juju-gui/pull/572 if someone's got a chance. [18:04] Makyo: +1 [18:05] Makyo: if hatch says +1 you've got mine thanks! [18:15] hatch: call time? I've got 15 [18:16] rick_h_: sure joining standup [18:28] * rick_h_ goes off to dr again, biab [19:13] hatch: I think I've got the bug accurately captured in a failing test… can you take a look and verify that I'm on the right track? [19:13] hatch: https://gist.github.com/kadams54/8a32eeee81e62031f17c [19:15] looking [19:15] The test sets up two endpoint sets that have one endpoint in common, but the other endpoint differs on the ID. The compareRelationEndpoints should return false because only one endpoint matches, but it does not. === fabrice|family is now known as fabrice [19:17] kadams54_: I don't think this test makes sense [19:17] Chat? [19:17] they can't relate because they require/provide the same thing [19:17] ok i'll hop in the standup [19:33] kadams54_: ping me when you get back if you get stuck - I'm interested in the resolution of this, relations are a pita :) [20:08] hatch: will do. I'm pretty sure I know how to fix it, but I still don't know exactly why it's breaking the way it is, and that bugs me :-) [20:08] haha - well...best of luck [20:08] lemme know if you need another sounding board [20:15] hatch: I don't think the problem is in flipping the endpoints, though I agree with your assessment that it's not doing what it's intended to do. [20:16] damn [20:16] Rather, the problem seems to be with the nested .some() functions that are looping through both sets of endpoints on line 1627-1631 [20:17] this was written in a rush for a demo I believe so it's entirely possible an edge case was missed (obviously) [20:17] heh [20:17] If I read them right, if any of the endpoints in the set match, then it will return true, when it should require *all* of the endpoints in the set to match. [20:17] damn I love writing code like this but wow is it hard to reason about later [20:18] well only one on each side needs to match [20:18] ohh nm rght [20:18] I need a good stiff drink and some painkillers [20:19] lol - who needs a liver anyways [20:54] kadams54_: hatch anything I can help with? [20:55] not here [20:55] Ditto - all good. [20:55] Unless you have some vicodin. [20:55] no, I've got the blue stuff [20:55] * rick_h_ can't recall the name now... [20:56] valium, that's it [20:56] moms little helper [20:56] This relations-induced headache keeps reminding me of Lucille Bluth's misinterpretation of the prescription warnings as "winking eye drink with alcohol" instructions. [20:57] that's valium right? [20:57] or how was it marketed....it was something like that [20:58] jcsackett: if MV flag gone gone? [20:58] yup valium http://en.wikipedia.org/wiki/Mother's_Little_Helpers [20:59] rick_h_: should be gone gone early tomorrow. [20:59] hatch: heh, well there you go. It's part of my anti-migraine regiment :) [20:59] jcsackett: ah ok. I saw no open cards for you and got curious [20:59] oh bah [20:59] :) [20:59] jcsackett: ignore me, I was looking at the top grouping [20:59] moving things around fooled me all up [21:00] rick_h_ it's done that to me a time or two as well. [21:00] Makyo: can I change your card to not blocked? Are we good now to update the button as appropriate? [21:00] can you tell when I get done with calls, all of a sudden very curious in everyone's cards :P [21:01] :p [21:02] antdillon: get our of here [21:02] bah, I need ops to kick him out of here [21:02] +ops [21:02] lol [21:02] stupid irc [21:02] antdillon: has a worse work/life balance than I do [21:02] rick_h_, thought I did, must not have hit submit, so yeah. [21:02] and he's about to have no sleep in life when the kid shows up [21:03] Just about to propose, anyway [21:03] Makyo: ok cool, card seem to be in good shape now with your last change? [21:03] One line fix, now :) [21:03] Makyo: ooh, yay. I was hoping that'd be easy now but was scared...nothing is easy these days [21:03] rick_h_, lol I have +1's damn it! [21:03] Makyo: cool, and then the notification card as a follow up on that one for tomorrow? [21:04] antdillon: :P [21:04] antdillon: apologize to robin for me. Poor guy got huw'd hard today [21:04] rick_h_, Yep. [21:06] rick_h_, lol hes been writing charms for IS with them reviewing ... your review it nice in comparison [21:06] antdillon: hah! ok, well normally we'd break someone new in a little easier [21:06] * rick_h_ runs away for a bit. I'll be back on tonight working in the blog post and such though if people need a hand/reviews in 3hrs [21:07] jujugui small review, QA in real env: https://github.com/juju/juju-gui/pull/577 [21:08] Makyo: lol [21:08] I recall that line being there at some point [21:08] Well, it's back :) [21:08] Going to exercise dogs, back in a few. [21:23] hatch: this relation comparison has turned into a real pita. It's seems like its not just a bug, but potentially a fundamental change in how we compare relations. [21:24] That is, the way we currently compare relations doesn't work when you have multiple relations that share one endpoint, but not the other. [21:25] kadams54_: I don't think you can have multiple relations sharing a single endpoint [21:25] Mongo cluster bundle [21:25] looking [21:26] All of the relations between the shards and the master all share one endpoint (the master) but have different endpoints at each of the shards. [21:26] ahhh [21:26] so yeah that's definitely not going to work with this [21:26] tbh I didn't know that was even possible [21:31] I'm going to need to think harder about this. [21:31] But that'll have to happen tonight. It's dinner time on the east coast. [22:58] Morning [22:59] mornin [23:19] jujugui another small one https://github.com/juju/juju-gui/pull/578 [23:19] Makyo: <3 [23:19] morning huwshimi [23:22] Makyo: comments in [23:23] Makyo: review done