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