[10:51] anyone noticed significant issues with the 1.21 alpah2 and gui? [12:16] hazmat: I am trying quickstart with the alpha version [12:16] hazmat: on a local run, quickstart never exits because the addresses in the mega-watcher for machines don't include a public scope [12:17] hazmat: e.g. http://pastebin.ubuntu.com/8703311/ [12:19] fwereade: ^^^ [12:23] frankban, i filed a bug [12:24] hazmat: thanks, number? [12:24] https://bugs.launchpad.net/juju-core/+bug/1386143 [12:24] Bug #1386143: 1.21 alpha 2 broke watch api, no longer reports all services

[12:25] the txt attachment shows some of the issues.. basically not all services appear in the megawatcher [12:26] as in very broken [12:28] hazmat: ok thanks, I'll add a comment to that bug re the issue with public addresses [12:37] hazmat: updated your bug, confirmed it affects the GUi as well [12:39] frankban, after i dug into the actual bug, i assumed as much in the initial reporting, allwatcher is just broken. [12:39] frankban, thanks for confirming [12:49] frankban: when you're back can you check out https://bugs.launchpad.net/juju-quickstart/+bug/1385407 as well. I'm guessing this is the bug jrwren_ ran into and that is now fixed in core. [12:49] Bug #1385407: juju-quickstart destroys existing AWS environment [12:50] frankban: it doesn't mention the juju version in the bug which will be the trick to making sure. But it's how jrwren_ brought down CI so core issue vs quickstart [12:53] :) [12:53] jrwren_: if you can find the bug/link to the fix to help frankban as it might be in your own bug history that'd be +1 [13:09] linked. [13:10] ty [14:51] jujugui call in 9 [14:52] because of osx yosemite issue I barely have an internet connection so I'll need someone to run this one [14:52] hey redir [14:52] yo! [14:52] how goes hatch ? [14:53] well osx yosemite has ruined my week - but other than that, it's going ok :) [14:53] and yourself: [14:53] ? [14:54] jcsackett: tell me if it's inline with your comments now for bundle vis [14:54] jcsackett: please [15:18] hey kyle how goes the conversion? [15:18] I'm pretty close to getting this thing ready to go - just took a few different approaches before I found one that made sense [15:19] kadams54: ^ :) [15:19] brain not working well today I guess hah [15:20] hatch: I'll have the refactor ready for review shortly. Cleaning up lint errors. [15:20] coolio [15:23] kadams54: over the weekend I was wondering why we don't mark the service models as faded/highlighted? It makes is about 1M times easier from the canvas side [15:23] I think we should [15:23] ok good, I am [15:23] Both services and units [15:23] heh [15:24] There's some duplication there and we could talk about whether setting on the service should cause the same flag to percolate automatically down to all units within that service. [15:24] hmm that's a good idea [15:25] I think what I'll do then is wait until your branch lands then go back and update it [15:25] else there are going to be a ton of conflicts [15:32] just ping me whenever you're ready for a review [15:54] hatch: us health insurance system paper work ruining my day^H^Hweek^H^Hmonth^H^Hquarter^H^H but other than that doing great:) [15:54] haha - wait, the US has health insurance? :P [15:55] I thought ya'll were still using leaches :P [15:55] hatch: the US has a health insurance market. Though it has little to do with health or insurance. [15:55] lol [15:56] hatch: they are leeches. [15:56] haha [15:56] hatch: I've actually had a fine experience over the last 10+ years, just horrid paperwork problems since changing providers. [15:57] ahh - yeah I have no idea how the system works, just fun to poke fun at it :) [16:02] hatch: https://github.com/juju/juju-gui/pull/628 is ready for QA and review. [16:02] kadams54: thanks [16:02] kadams54: you answsered this last week but I can't remember - can you highlight and fade? [16:03] so the icon will be different but faded? [16:03] No, not on the same service. [16:03] ok [16:03] You can highlight a service and one of its related services can be hidden. [16:04] At which point the highlighted-but-hidden related service needs to be faded to 20% [16:05] kadams54: did you make any changes to the moved code? Or was it just a copy/paste [16:05] Copy-n-paste. [16:06] coo [16:06] l [16:06] And the new tests reflect the current (wrong) behavior, so there were aspects I didn't even bother changing. [16:06] sure - but what about the old tests? [16:06] or were there no old tests? heh [16:06] Er, "didn't even bother testing", not "didn't even bother changing" [16:06] Very few old tests, if any [16:06] None that directly tested [16:07] oh jeesh ok thanks [16:07] hah - this is why we need more of these extensions lol [16:11] kadams54: review done - I vote to land it once the tests run so we can keep truckin along [16:11] K [16:11] jujugui can we get another review on #628 [16:22] dart virtual dom vs reactjs benchmark http://localvoid.github.io/vdom-benchmark/ looks like dart is faster - at least according to this benchmark [16:30] kadams54: shippit? [16:31] hatch: Done. [16:31] nice [16:31] just don't want to get held up heh [16:31] (although I seem to be holding myself up :?) [16:31] :/ [16:37] the undocumented show/hide/highlight/fade methods and their differing call signature is driving me batty [16:44] Ah yes… I had a branch where I documented them. Not sure what happened to that. [16:51] it's ok I've got it working now just super frustrating because they look the same but are slightly different [16:58] kadams54: so I'm just doing https://gist.github.com/hatched/41657f7e8bf45d5dc84d in the handlers [16:58] is that the same direction you are going? [16:58] Sure. [16:59] Pretty much [16:59] oh you haven't started? :) [16:59] I just saw the card in coding [16:59] haha [16:59] I'm eating lunch :-) [16:59] oh haha sounds good [16:59] are you also going to move the unit updating into the service? [17:00] lets have a chat when you're done lunch [17:00] just want to limit the conflicts [17:00] wb Makyo you workin today? [17:01] hatch, Yep, I just took a half day since I worked half of Thursday. [17:01] ahh coolio [17:01] good trip? [17:02] Very! I didn't look at a laptop once. [17:03] haha nice those are the best kind [17:08] kadams54: this is the approach I settled on for the service topology stuff https://github.com/hatched/juju-gui/compare/juju:develop...hatched:canvas-fade?expand=1 [17:08] the same needs to be done to the relationship side [17:08] but I think it's easier to reason about this way [17:09] this of course assumes that the service models are updated accordingly [17:11] hatch: OK, give me 5 minutes and then we'll chat? [17:12] yeah np [17:15] frankban: https://bugs.launchpad.net/juju-gui/+bug/1383381 this done? can you update the bug [17:15] Bug #1383381: autoplaced units don't show up in machine list [17:25] hatch: Ok, ready when you are. [17:25] kadams54: ok it might be a bit - I'm just debugging a gui issue with a user atm [17:25] np [17:25] will ping when I can [17:28] kadams54: ok I can probably do both at once [17:28] :) [17:28] see u in standup room [17:28] Yay multitasking [18:16] jujugui can anyone confirm if juju uses the lowest possible unit id's for new units or always goes +1 from the last id regardless if that unit still exists? [18:16] I am pretty sure it always +1's the last one whether it exists or not [18:16] hatch: +1 [18:16] thanks sir [18:17] hatch: how do you want to use this assumption? [18:18] frankban: https://bugs.launchpad.net/juju-gui/+bug/1375918 this context will help you understand :) [18:18] Bug #1375918: units can be created without a service causing cascading failures [18:18] frankban: essentially I'm not sure what the GUi can do but create temporary id's like we do with services [18:20] hatch: so basically no assumption on the next id sounds good, because it's unpredictable [18:20] right - but we need unique id's for ghost units [18:20] so we'll have to switch this over to using temporary ids like we do for services [18:21] quite a bit more work to fix than I had originally thought heh [18:21] hatch: yeah, for the machines I used an internal counter and a "new" prefix, perhaps we can do the same for units? [18:21] yeah that's possible [18:22] I'm just so glad he helped me debug the issue heh [18:24] :-) good night all, done for the day [18:24] night frankban [18:50] hatch: how do you want to handle related services for something like highlight? [18:50] i.e., should I set any flags on them? Or are you going to handle finding them and styling them appropriately based on the one service having a highlight flag? [19:03] kadams54: sorry just cooking lunch [19:03] kadams54: yes the topology should be able to just parse the db for what it needs to hide/highlight [19:04] so that should be done in the handler imho [19:04] Except that nothing gets set in the DB for related services [19:04] There is no "your relation is highlighted" flag [19:06] ohh [19:06] hmm that's a good point [19:06] that'll have to be done in the relationship update handler? [19:07] I could handle it in browser by creating three sets: the targeted service, the related services, and the unrelated services. [19:08] targeted.highlight = true, unrelated.fade = true, related -> noop [19:09] hmm nah then we aren't using the db as the source of truth [19:09] ok lunching [19:12] why does it make sense to make search queries with limit=1000? [19:31] urulama: because 1001 runs the system out of memory? [19:31] ;) [19:31] kadams54: back - what did you think of my comment? [19:32] hatch: :P just checking that it's not some final call :) [19:33] haha I have no idea - 1000 results over the wire would certainly put something in limp mode [19:49] hatch: not sure I follow. Why would we not be using the DB as a source of truth? [19:49] well where would this object be? [19:49] targeted, unrelated etc [19:51] They're just lists of models. [19:51] quick chat? I think we are crossing ideas here [19:51] And then I'd iterate through and set the appropriate flags [19:52] I have my 1/1 with Robbie in 10. [19:52] it'll be quick I promise :) [19:52] k [20:00] Anyone else had their 1/1 with Robbie yet? [20:01] I have [20:08] I did before the sprint. [20:49] kadams54: ok I think I have the relation one done - I'll bench this branch now until yours lands [20:49] is there anything else I can help on now? [21:22] hatch: I need some dog food from the grocery store. [21:23] well there is your problem - don't get dog food from a grocery store [21:25] unless of course you have a progressive grocery store that sells something other than that made in 'who knows where' garbage [21:58] kadams54: it's your EOD now? [22:32] evening [22:33] welcome back fearless leader [22:33] I saw your team lost [22:33] not that we expected anything else ;) [22:34] :( it was quite brutal [22:34] more than a loss, a thorough beat down [22:34] for that I have this https://play.google.com/music/m/Tugnjibik2twwzbrudbnvjc5cfi [22:35] well THAT link didn't work [22:35] worked here [22:35] oh good :) [22:36] since I upgraded to yosemite my internet is absolute garbagio [22:36] can https://plus.google.com/photos?pid=6074616927809511298&oid=116120911388966791792 work for you? [22:36] heh, not upgraded at all here [22:36] just a black screen [22:36] :( [22:36] hmm, just have your canonical G+ [22:37] lemme go reboot my router - maybe that'll help [22:37] hah [22:43] rick_h_: even the email doesn't work [22:43] sure you have the permissions open? [22:43] ahah I got it [22:43] hatch__: ? I just shared it with your work google plus account [22:43] you have to go there to get it [22:43] yeah [22:44] part of stupid G+ getting rid of way to share photos via a url :( [22:44] sweet shot [22:44] yea, google auto awesome'd one of my shots in the game of brady tossing another TD against my team [22:45] lol [22:45] salt in the wound [22:46] yea, well the salt was to pay the $$ to fly out there, get awesome seats, and watch a game that wasn't even competitive. [22:49] yeah I could see that === hatch__ is now known as hatch === hatch is now known as Guest35185 [22:53] *sigh* stupid freenode