| rick_h_ | jujugui new release is out | 03:01 |
|---|---|---|
| rick_h_ | http://jujugui.wordpress.com/2014/11/04/juju-gui-1-2-3-released/ | 03:01 |
| rick_h_ | urulama: you really here? | 03:01 |
| === kadams54 is now known as kadams54-away | ||
| huwshimi | rick_h_: Nice! | 03:21 |
| rick_h_ | hazmat: bug fix release out, hopefully helps. ^ | 03:23 |
| huwshimi | rick_h_: Is there a flag to view the added services panel? | 03:25 |
| rick_h_ | huwshimi: /:flags:/as | 03:25 |
| rick_h_ | huwshimi: it's still a couple of cards from landing, hopefully done later this week | 03:25 |
| huwshimi | rick_h_: Oh, I should have looked at the full changelog :) | 03:25 |
| rick_h_ | :) | 03:25 |
| huwshimi | rick_h_: And how do you actually show the add services panel? :) | 03:27 |
| rick_h_ | huwshimi: deploy something so you have added services? | 03:31 |
| rick_h_ | huwshimi: and then under the search bar is a button that opens it | 03:31 |
| rick_h_ | huwshimi: find it? | 03:33 |
| huwshimi | rick_h_: Oh, I was trying on jujucharms.com | 03:33 |
| rick_h_ | huwshimi: oh yea, comingsoon | 03:34 |
| rick_h_ | huwshimi: since we're trying to bring up the new site didn't bother updating that url yet | 03:34 |
| huwshimi | yeah :) | 03:34 |
| huwshimi | I'm not a person | 03:34 |
| rick_h_ | not a person? | 03:35 |
| huwshimi | rick_h_: I have no brain? I am not functioning :) | 03:36 |
| huwshimi | wait, that wasn't a question | 03:36 |
| huwshimi | or was it? | 03:36 |
| rick_h_ | it was, I didn't follow the 'I'm not a person' line | 03:38 |
| rick_h_ | but gotcha now, some funky saying :P | 03:38 |
| === kadams54 is now known as kadams54-away | ||
| hazmat | rick_h_, sweet | 08:26 |
| hazmat | so another gui bug, resolve/retry doesn't go through commit | 08:48 |
| === rogpeppe1 is now known as rogpeppe | ||
| rick_h_ | hazmat: hmm, yea that was intentional. The thought was that doing a resolve/retry isn't really a part of a 'changeset' you'd be trying to put together | 14:48 |
| rick_h_ | hazmat: more of a debugging command that you want to happen | 14:48 |
| hatch | Makyo: u in yet? | 15:06 |
| hatch | kadams54: so could you do the added services ui buttons respecting the service visibility state? | 15:10 |
| kadams54 | hatch: yeah. | 15:11 |
| hatch | I don't think that will conflict with my stuff | 15:11 |
| hatch | right now I'm trying to figure out why ghost services get selected differently by d3 | 15:11 |
| hatch | :/ | 15:11 |
| kadams54 | hatch: I don't see a card for that? | 15:12 |
| hatch | hmm I was wrong they are getting selected the same... | 15:12 |
| hatch | oh I don't know if there is one | 15:12 |
| hatch | lookin | 15:12 |
| kadams54 | If not, I can create one | 15:13 |
| hatch | now there is | 15:13 |
| kadams54 | guihelp: anyone know what the diff is between the agent_state_info and agent_state_data fields on a unit? | 15:14 |
| hatch | ahh now I see the issue - css properties override the dom attributes with svg's | 15:15 |
| hatch | kadams54: it might be left overs from the pyjuju > juju-core conversion | 15:15 |
| hatch | why u ask? | 15:15 |
| kadams54 | I'd grabbed a card from the maintenance bugs. The GUI is falling over (uncaught exception) when dealing with endpoint errors. | 15:16 |
| hatch | oh - no reproduction steps | 15:17 |
| hatch | hah | 15:17 |
| kadams54 | The code currently checks unit.agent_state_data when, at least in this situation, that field is not set. From reading code comments, it seems like it should actually check unit.agent_state_info. | 15:17 |
| hatch | I don't think that's the case | 15:18 |
| hatch | without repro steps how are we to know if the bug is fixed? | 15:18 |
| hatch | I'd reply asking for steps on repro | 15:18 |
| rick_h_ | hatch: it's not that simple | 15:19 |
| kadams54 | That's fine, but there's enough info that I can write a test to reproduce the error condition. | 15:19 |
| rick_h_ | hatch: that bug was from a running env without real steps. There was something when a unit was removed was the comment | 15:19 |
| rick_h_ | It'll be a 'try to catch this known error by being more defensive' | 15:19 |
| hatch | well it appears that there was a failure with a unit being removed causing it's agent data to be cleared out | 15:19 |
| hatch | that shouldn't happen - so the issue is somewhere up the stack | 15:19 |
| rick_h_ | hatch: right, and that broke the gui | 15:19 |
| kadams54 | agent_state_info was still set | 15:20 |
| rick_h_ | hatch: sure, juju probably did something bad | 15:20 |
| kadams54 | We could have looked in there to see that there was an error in the relation | 15:20 |
| rick_h_ | but we need to try not to break if we can help it. | 15:20 |
| kadams54 | Which is what this code is trying to do | 15:20 |
| hatch | what I'm concerned about is just covering over the issue instead of resolving the root cause | 15:21 |
| rick_h_ | hatch: understood, but it's not a simple reprdocing issue and there was no work around to help debug further | 15:21 |
| kadams54 | *Our* issue is bad error handling. | 15:21 |
| kadams54 | We can address that, which may help in uncovering/addressing the root cause. | 15:22 |
| rick_h_ | +1 | 15:22 |
| hatch | sure - but lets step back through the sequence of events which would have caused agent_state_data to be undefined | 15:22 |
| kadams54 | So I'm reasonably confident that 1) I can write a unit test that reproduces the error condition and will allow us to say that the bug is fixed and 2) that we ought to be checking both agent_state_data AND agent_state_info fields for the name of the relation. | 15:22 |
| rick_h_ | hatch: sure, walk the code and see what could have emptied it | 15:23 |
| hatch | what I'd first like to do is figure out the difference between info and data | 15:23 |
| hatch | I am pretty sure that data is the new field added in juju-core | 15:23 |
| hatch | for things like relation issues and the like | 15:23 |
| kadams54 | Except in this case data isn't there. And info is. And info has the relation issue reported in it. | 15:24 |
| hatch | right | 15:25 |
| hatch | but they were different formats | 15:25 |
| hatch | data was added (I believe) to give us more detailed easier to parse information about the units | 15:25 |
| kadams54 | Which is great, if it's there. | 15:25 |
| kadams54 | What I'm saying is that our error handling code ought to check data, and if it's not there, fall back to info. | 15:26 |
| kadams54 | Instead of just making assumptions that data will always be there. | 15:26 |
| hatch | that's fine to do, but before you do that first understand what info and data are and why data was removed when info wasn't | 15:26 |
| kadams54 | I don't think that's necessary to write good error handling code. | 15:26 |
| kadams54 | I think it would be good as a follow-up task. | 15:27 |
| hatch | so you know that info contains the exact same information as data is checking for? | 15:28 |
| kadams54 | But good error handling code ought not make any assumptions. Check data first, then info, and if neither is there, do the best you can… but don't trigger a null error. | 15:28 |
| kadams54 | unit.agent_state_data.hook.indexOf(endpoint[1].name + '-' + 'relation') === 0; | 15:28 |
| kadams54 | It's checking to see if the relation name is in the hook | 15:28 |
| kadams54 | We already know agent_state is "error" | 15:28 |
| kadams54 | We also know, from juju status, that this is what was in info: 'hook failed: "homer-relation-joined"' | 15:29 |
| kadams54 | So if that bit of code had just checked for the relation name in both fields (in a manner that didn't assume either field existed), it would've worked fine. | 15:29 |
| hatch | right - but there was a reason why we didn't use that and instead added the data attribute | 15:33 |
| hatch | I'm just saying - do all the error checking you want, but make sure you understand why data was no longer available | 15:33 |
| * hatch pinging Makyo hatch to Makyo, calling all Makyo's | 15:34 | |
| kadams54 | hatch: as best I can tell, we don't directly set or clear data in our code, which means that it was likely cleared/not set in juju-core. | 15:35 |
| hatch | ok if that's the case then we need to file a bug with juju-core | 15:35 |
| hatch | it's removing the data prematurely | 15:36 |
| kadams54 | I agree, but we also need to not fall down when juju-core does something wrong. | 15:36 |
| hatch | we just need to pop this image up http://i0.kym-cdn.com/photos/images/newsfeed/000/774/489/829.jpg | 15:38 |
| kadams54 | :-) | 15:40 |
| hatch | ok I'm going to ignore the not fading ghost services thing and get what I have ready to land - getting ghost services to fade/hide requires changing the d3 fade bits to use css instead | 15:43 |
| hatch | ^ rick_h_ | 15:43 |
| hatch | I fixed it so that it no longer throws an error, but it still doesn't fade/hide (ghosts) | 15:43 |
| rick_h_ | hatch: rgr | 15:44 |
| hatch | follow-up can do that stuff - but got to get this thing landed so it can be qa'd really hard by peeps :) | 15:44 |
| rick_h_ | :) | 15:45 |
| rick_h_ | jujugui call in 10 kanban please | 15:51 |
| rick_h_ | Makyo: call | 16:00 |
| rick_h_ | jcsackett: call | 16:01 |
| kadams54 | rogpeppe, fabrice: that's interesting about the lack of options. I'm always hearing about how Europeans have more options because they don't have the duopoly we have here. In the US, for the most part, you can get your internet from the phone company or the cable company (if you can get it at all). There's very little competition. | 16:18 |
| fabrice | same here except in big towns | 16:18 |
| rogpeppe | kadams54: i have provider options but the only connectivity is copper around here | 16:19 |
| rogpeppe | kadams54: http://www.speedtest.net/my-result/3883355136 | 16:19 |
| fabrice | kadams54: I have a few provider but they all go to the same physical lines | 16:19 |
| rogpeppe | http://www.speedtest.net/result/3883355136.png | 16:19 |
| fabrice | kadams54: tehy don't bring a lot of different cable to individual house in France | 16:19 |
| kadams54 | rogpeppe: Yeah, copper is also the only option for a lot of places in the US. Not sure if fiber would be an option where I live, but it's moot because I already know it's out of my price range. | 16:20 |
| rogpeppe | that is quite a bit crapper than usual | 16:20 |
| * rogpeppe goes to complain to the ISP | 16:20 | |
| fabrice | kadams54: but if I was on fiber it will be the same price 30 euros | 16:20 |
| hatch | kadams54: did I mention fiber is cheaper than copper here? ;) | 16:21 |
| hatch | (because it damn well should be) | 16:21 |
| kadams54 | hatch: yeah, I kinda hate you. | 16:21 |
| kadams54 | Every time you complain about the fiber being put in. | 16:21 |
| hatch | well it's slow as crap right now | 16:21 |
| hatch | 600kbps | 16:21 |
| hatch | :P | 16:21 |
| hatch | they say they are fixing it, but I'm just glad they aren't digging in my yard anymore | 16:22 |
| hatch | I am actualy surprised that more places don't have crown owned telco's | 16:22 |
| hatch | crown being govt (not sure if that terminology crosses borders) :) | 16:23 |
| kadams54 | Why's that? | 16:23 |
| kadams54 | As an American, the only thing worse (to me) than the current duopoly would be a government-owned monopoly. | 16:24 |
| hatch | because a crown corp can run at a low margin because it's goal is to provide a quality service, not fatten the wallets of some billionares | 16:24 |
| hatch | so (in theory) you would get better service for less $ | 16:24 |
| kadams54 | You have a high opinion of the ethics of bureaucrats and politicians. | 16:25 |
| kadams54 | ;-) | 16:25 |
| hatch | our telco is run as it's own company (owned by the govt) | 16:25 |
| hatch | and it's hugely profitable | 16:25 |
| hatch | and we have 2 other competitors here | 16:25 |
| hatch | which basically means the 'big corps' are screwing everyone | 16:25 |
| hatch | because this is proof that you can provide a quality service with low population over large distances | 16:26 |
| hatch | I think we barely have 1M people | 16:26 |
| * kadams54 scratches his head. | 16:28 | |
| kadams54 | I like how you say everyone's being screwed but then turn around and say "quality service" in the next statement :-) | 16:28 |
| Makyo | hatch, standup? | 16:28 |
| hatch | right - I am not on a big corp telco | 16:29 |
| hatch | Makyo: sure joining | 16:29 |
| rogpeppe | interesting, it might bit my wi-fi playing up. i tried plugging in directly and got a much better result http://www.speedtest.net/result/3883389667.png | 16:32 |
| kadams54 | wow, indeed | 16:32 |
| kadams54 | Though that up is still painful | 16:32 |
| rogpeppe | it's supposed to be 802.11n too. | 16:32 |
| kadams54 | You know what that means… | 16:33 |
| kadams54 | Time to go get an 802.11ac access point :-) | 16:33 |
| rogpeppe | there's definitely something playing up in one of my ether switches recently - one my two wi-fi networks refuses to a NAS box in the attic that's attached to the other | 16:33 |
| hatch | Makyo: so that got it to work, unfortunately it exposed another bug :/ lol | 16:46 |
| Makyo | hatch, sigh, programming 9.9 | 16:46 |
| hatch | Makyo: I don't understand your new-age-emoji | 16:48 |
| hatch | what ever happened to the classics??????? | 16:49 |
| Makyo | It's eye-rolling. Come on :P | 16:49 |
| hatch | really?? | 16:49 |
| hatch | I thought it was crying | 16:49 |
| Makyo | Yeah, like the . is the nose and the 9s are the eyes | 16:49 |
| hatch | man I would suck as a teen now | 16:49 |
| Makyo | 9.6 | 16:49 |
| Makyo | Hahaha | 16:49 |
| hatch | stoned | 16:49 |
| hatch | that one is stoned right? | 16:49 |
| Makyo | Haha, sure :) | 16:49 |
| hatch | henceforth be known as The Denver | 16:50 |
| Makyo | Which makes a "Denver omelet" kind of spectacular | 16:50 |
| hatch | haha | 16:51 |
| hatch | kadams54: after merging in develop again I'm having issues with the unhighlight event order of events for making sureonly one thing can be highlighted at a time | 17:23 |
| hatch | I think it will need to be changed to work as a method instead of an event - or the event will need to carry with it the token that it's supposed to skip | 17:24 |
| hatch | I swear this code never ends | 17:24 |
| hatch | it appears to only be out of sync with ghost services?!? | 17:25 |
| hatch | yeah - looks like the time it takes to parse the service list is enough to cause the events to get out of order | 17:26 |
| kadams54 | hatch: I'd like to try a patch | 17:35 |
| kadams54 | hatch: http://pastie.org/private/spwbpol1p5aqbjovclha | 17:36 |
| kadams54 | That will eliminate all of the unecessary events. | 17:36 |
| hatch | kadams54: cool Ill give it a go | 18:01 |
| hatch | thx | 18:01 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| kadams54 | hatch: did that patch help? | 18:35 |
| hatch | not sure - had started lunch, broke for a qa, now lunching again :) | 18:35 |
| Makyo | jujugui tiny branch for review/qa https://github.com/juju/juju-gui/pull/639 | 18:50 |
| kadams54 | Makyo: looking | 18:50 |
| kadams54 | Makyo: looks good | 18:56 |
| hatch | kadams54: unfortunately that patch didn't work - the service highlights but the token unhighlights leaving the service highlighted | 19:23 |
| hatch | very odd | 19:23 |
| kadams54 | OK… give me a few minutes and then maybe we can pair? | 19:23 |
| hatch | I was just going to leave it until I can get this branch landed | 19:25 |
| hatch | need to get this branch in then we can follow it up with fixes | 19:26 |
| hatch | get people using it and such | 19:26 |
| kadams54 | Yeah, that works too | 19:27 |
| kadams54 | Can you be sure to include that patch in your branch? | 19:27 |
| kadams54 | Even if it doesn't address this issue, it still needs to be in there. | 19:27 |
| * Makyo zoom to appointment, back in a bit | 19:30 | |
| hatch | yep can do | 19:30 |
| kadams54 | jujugui: looking for reviews on https://github.com/juju/juju-gui/pull/640 - not sure how possible QA is. | 19:36 |
| kadams54 | hatch: thanks | 19:36 |
| hatch | well THAT was a violent crash | 19:51 |
| kadams54 | Eh? | 19:53 |
| hatch | vm took down the whole computer | 19:54 |
| === kadams54 is now known as kadams54-away | ||
| hatch | http://www.codingame.com/home/platinum-rift coding challenge battle heh | 20:50 |
| hatch | mhall119: hey can employees of Canonical participate in the scopes callenge? | 20:58 |
| mhall119 | hatch: not this time, no | 21:02 |
| hatch | mhall119: booo | 21:03 |
| mhall119 | hatch: but don't let that stop you from writing a scope :) | 21:03 |
| hatch | haha | 21:03 |
| hatch | I just wish it opened faster | 21:03 |
| hatch | Makyo: I'm investigating the outline issue you noticed. turns out something was changed in this branch that's causing this line to not work | 21:15 |
| hatch | curr_node.attr({'xlink:href': new_href}); | 21:15 |
| hatch | new_href is the proper path but the icon isn't being updated | 21:15 |
| hatch | oh I think I found it | 21:18 |
| hatch | Makyo: d3 question https://github.com/hatched/juju-gui/blob/canvas-fade/app/views/topology/service.js#L1494 | 21:28 |
| hatch | I need to determine while looping through these selections what to set the icon to | 21:29 |
| hatch | so I was thinking selection.each(function(d) ... ) buuut it doesn't look like I can get from the object 'd' to the element to set it | 21:31 |
| hatch | I'm sure I'm missing something obvious though | 21:31 |
| hatch | ohhh `this` is the element | 21:32 |
| hatch | I knew it was something obvious :) | 21:32 |
| hatch | selection.each(function(d) { d3.select(this).select('.service-block-image'); }); | 21:34 |
| huwshimi | Morning | 22:02 |
| hatch | mornin! | 22:02 |
| huwshimi | hatch: Hey :) | 22:03 |
| === kadams54-away is now known as kadams54 | ||
| hatch | jeesh playing wakamole with these tests | 22:15 |
| hatch | I've literally had 5 failing tets for 4 hours and been fixing them constantly | 22:16 |
| === kadams54 is now known as kadams54-away | ||
| * Makyo returns. | 22:20 | |
| Makyo | Problem solved, hatch ? | 22:20 |
| hatch | yeah that one was 2 problems ago | 22:21 |
| hatch | :/ | 22:21 |
| hatch | these d3 tests use so many kludges that it's trying to figure out wth is going on first | 22:21 |
| Makyo | Yeah :/ | 22:21 |
| hatch | can a subordinate relation not go bad? | 22:23 |
| hatch | right now I'm working on https://github.com/juju/juju-gui/blob/develop/test/test_environment_view.js#L1165 | 22:24 |
| hatch | this is failing because iRemainUnchanged isn't in the path | 22:24 |
| hatch | but the path is correct without that | 22:25 |
| hatch | so I think that this test is just wrong | 22:25 |
| hatch | but I am not sure what it's actually testing :/ | 22:25 |
| hatch | Makyo: maybe you can shed some light on this one ^ | 22:25 |
| hatch | Makyo: it was actually you who added it in response to some review comments c858ac02 | 22:31 |
| hatch | https://github.com/juju/juju-gui/commit/c858ac02 | 22:32 |
| hatch | not entirely sure why that change was made | 22:33 |
| hatch | https://github.com/juju/juju-gui/commit/f37d4787a1675d13e9dc4cc4cd42e206b04a9c6b | 22:33 |
| hatch | not sure how to get to the PR from there (unless this was a reitveld one) ? | 22:34 |
| hatch | after a bunch of testing it doesn't appear to be necessary any longer | 22:39 |
| hatch | removing | 22:39 |
| hatch | holy I'm now down to 4 tests failing lol | 22:45 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| kadams54 | jujugui: still looking for reviews on https://github.com/juju/juju-gui/pull/640 | 22:57 |
| Makyo | Wooo~ | 22:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
