[13:50] <frankban> guihelp: another quick fix to the GUI: https://github.com/juju/juju-gui/pull/627
[14:06] <kadams54> frankban: taking a look
[14:06] <frankban> ty
[14:11] <kadams54> frankban: looks good.
[14:11] <frankban> kadams54: great thanks
[14:12] <kadams54> hatch: let me know when you're available.
[14:12] <hatch> kadams54: just responding to your replys
[14:13] <kadams54> hatch: yesterday you talked about moving the event handling into an extension… why?
[14:13] <kadams54> Or maybe I'm misunderstanding?
[14:13] <hatch> just the handlers
[14:13] <hatch> it's because these views are getting unweildy and difficult to test
[14:13] <kadams54> OK
[14:13] <kadams54> Agreed.
[14:13] <hatch> as an extension we can easily test the handlers separate from it all
[14:17] <hatch> kadams54: also this branch is missing tests
[14:17] <hatch> did you forget to add them to the commit?
[14:17] <kadams54> No.
[14:18] <kadams54> I'm adding tests in my current branch.
[14:19] <hatch> oh they should probably go in this one if I'm going to be building on top of this code and possibly modifying it
[14:20] <hatch> kadams54: I have a wierd issue with the machine view qa
[14:20] <hatch> if I highlight two services then no machines are visible
[14:20] <kadams54> hatch: You confident enough in our approach to wrap it in tests?
[14:20] <kadams54> hatch: yeah, don't do that.
[14:21] <hatch> it's just a utility method
[14:21] <hatch> lol what do you mean don't do that? Is this a bug?
[14:21] <kadams54> Stuff involving multiple buttons being pushed doesn't work yet.
[14:22] <kadams54> The spec is divided up into 3 sections: hiding, highlighting, and cross over (multiple states invoked at once)
[14:22] <kadams54> cross over wasn't addressed by this card
[14:23] <hatch> ahh yeah we don't modify the db for machines anywhere
[14:25] <hatch> kadams54: didn't we get a new icon for the highlight?
[14:25] <kadams54> hatch: not sure what you mean by "it's just a utility method". findUnrelatedServices() needs tests for sure, but that's not what I'm worried about. It's the changes in renderUnits() in both contianer-token.js and machine-token.js.
[14:25] <kadams54> hatch: not yet. We were promised one, but it has not arrived. luca?
[14:26] <hatch> kadams54: findUnrelatedServices has a very similar usecase to getRelationDataForService
[14:26] <hatch> the latter is a util method so why isn't the former
[14:26] <hatch> the former needs access to things it coudln't possibly know about
[14:26] <hatch> db and utils
[14:26] <kadams54> Becasue I don't think the latter should be a util method.
[14:27] <kadams54> And I reject your assertion that it couldn't, because it does :-)
[14:27] <hatch> methods on a model should only ever interact with the data in that model
[14:27] <kadams54> False
[14:28] <kadams54> Model methods can also deal with relations that the model has to other models
[14:28] <hatch> no because then you have to pass that in
[14:28] <hatch> you then have to stub all that in tests
[14:29] <hatch> it's a clear hierarchy that's being violated 
[14:29] <hatch> the child (model) shouldn't need to know about it's parent (modellist) or grandparent (db)
[14:29] <kadams54> It's possible that I'm just not groking the hiearchy here, but I was kinda surprised that the models here had no way to refer back to the DB.
[14:29] <hatch> that's intentional 
[14:30] <kadams54> That's not my experience with models in other MVC frameworks
[14:30] <kadams54> How do you deal with one-to-many relations?
[14:30] <kadams54> i.e., a machine that contains many units?
[14:31] <hatch> YUI is based on OOP
[14:31] <kadams54> I agree that it's less than ideal to pass the DB in, but IMO that's only because the model ought to have a way to get back to the DB baked in.
[14:31] <kadams54> LOL
[14:31] <hatch> in OOP you don't know about your parents
[14:31] <hatch> one to many relations are pushed up the stack
[14:31] <hatch> either to the modellist or to the db
[14:33] <kadams54> That restriction, that models can only operate on their own internal data, seems to relegate them to pretty dumb objects.
[14:33] <hatch> exactly
[14:33] <hatch> that's the whole point 
[14:33] <hatch> take a look at Lazy Model Lists - they ARE just objects 
[14:34] <kadams54> Sure, but I thought that was a concession for performance
[14:35] <rick_h_> dumb objects ftw
[14:35] <kadams54> rick_h_: bah
[14:35] <rick_h_> :)
[14:36] <kadams54> In my experience, particularly in the Java world, dumb data objects lead to incredible code bloat.
[14:37] <rick_h_> ime dumb objects lead to great testability, easy resuability, and easier debugging
[14:37] <hatch> "...in the Java world...incredible code bloat..." there I fixed it for you :P
[14:37] <kadams54> They couldn't do anything, so you had to write all these other classes that manipulated them. DOs were wrapped by DAOs so you could do data query operations. Then the controllers took the DOs out of the DAOs and re-wrapped them in some other view object whose name escapes me, to prep the object for the view.
[14:37] <kadams54> Don't get me wrong. Fat models are also bad.
[14:38] <kadams54> But the truth is in the middle.
[14:38] <rick_h_> kadams54: hatch I'm not up on the whole conversation, just speaking in general terms the GUI's been bitten by parts that were too smart for their own good and we've learned that dumber parts (widgets, models, etc) have helped the gui over the long run
[14:40] <kadams54> I'll do it as a util method, but under protest. util methods suck.
[14:40]  * rick_h_ reads more of backlog
[14:40] <hatch> I'm ok with that :)
[14:41] <kadams54> Just as a general concept… I tend to be opposed to putting things in utils because all too often it turns into an unwieldy dumping ground for code bloat.
[14:41] <hatch> yeah I agree with that
[14:41] <kadams54> So your objects are all nice and clean and shiny because you just outsourced the crufty stuff to a monster 5000 line mish-mash of "utils"
[14:41] <hatch> but you could put it in the db
[14:41] <hatch> and typically you have multiple utils files 
[14:42] <hatch> (we only have 3) :P
[14:42] <kadams54> IMO the DB ought not know about the relations within it. ServicesList seems like the better fit to me.
[14:43] <rick_h_> hmm, so just reading the backlog, the method findUnrelatedServices seems like it'd be something I'd call on a db passing in a service.
[14:43] <kadams54> Though, per my comment on the PR, it doesn't seem like the type of aggregate operation that is intended for ModelList.
[14:43] <rick_h_> someone link me to the source?
[14:43] <kadams54> https://github.com/kadams54/juju-gui/blob/hide-highlight-tweaks/app/models/models.js#L313-L328
[14:44] <hatch> rick_h_: I also commented on your question in my PR https://github.com/juju/juju-gui/pull/624#discussion_r19251726
[14:44] <rick_h_> so yea, anti it being on service, but +1 on it being up the stack there in the service list/db.services
[14:44] <rick_h_> vs a util
[14:44] <hatch> I'll go with that
[14:44] <rick_h_> just to toss in my .02
[14:45]  * hatch throws in his .02 
[14:45]  * hatch hopes kadams54 isn't rich
[14:45] <kadams54> hatch is in luck.
[14:45] <hatch> lol
[14:45] <hatch> I was waiting for you to drop $1 on there :P
[14:45] <kadams54> OK, I'll move it up to the servicelist and add a test.
[14:45] <hatch> udaman
[14:45] <kadams54> Anything else needed to land this branch?
[14:46] <hatch> well I'm curious about your concern for the render method
[14:46] <hatch> it looked fine to me
[14:46] <hatch> am I missing something? :)
[14:46] <kadams54> The changes need to be tested, but the underlying code seemed very hacky to me…
[14:47] <kadams54> Though that was before our chat yesterday.
[14:47] <kadams54> I was going to write more functional-ish tests that exercised the UI-facing bits of code as part of moving away from custom events and towards database changes.
[14:48] <hatch> ahh - well the render code looks good - I think that once we make the 'db the source of truth' stuff then it's easy to reason about 
[14:48] <kadams54> Yeah, sounds good. Test findUnrelatedServices in this branch, test the rendering in subsequent branches.
[14:48] <kadams54> Is that a correct summary?
[14:49] <rick_h_> hatch: kadams54 and I'm going to pull the 'remember my settings' card for now. I want us to focus on using the feature/etc over that
[14:49] <hatch> kadams54: yep that fine - just make sure those tests get in there later ;)
[14:49] <kadams54> I'm not familiar with that card?
[14:50] <hatch> rick_h_: kadams54 yep that's good I already marked it as low
[14:50] <kadams54> Oh, nevermind
[14:50] <hatch> :)
[14:50] <kadams54> I thought you meant a "card" as in "I'm pulling the team lead, master-of-the-universe card.", not as in an actual kanban card. :-)
[14:51] <rick_h_> kadams54: oh, no I try to keep my 'team lead' cards in a box on the desk
[14:51] <hatch> when that box drops, you'll know
[14:51] <kadams54> Right next to the Crimes Against Humanity box, right?
[14:51] <kadams54> ;-)
[14:51] <hatch> california will finally split from the US via an earthquake 
[14:54] <Makyo> jujugui call in 6
[14:56]  * hatch just realize hatch and Makyo are the same character length
[14:56] <Makyo> It's only been, what, a year and a half?
[14:57] <hatch> pretty close to 2 yep :)
[15:00] <hatch> trying to join
[15:00] <rick_h_> kadams54: frankban Makyo ^
[15:33] <hatch__> guess I'm going to have to spin up a new vm with utopic on it now
[16:01] <hatch> I'm really curious if we could do the canvas with react...
[16:12] <hatch> frankban: +1 on your GUI branch
[16:13] <hatch> my GigE router has a max transfer rate of about 50MB/s
[16:13] <hatch> lol false advert much?
[16:18] <frankban> hatch: thanks
[16:22] <jrwren> hatch: that is max gigE
[16:23] <jrwren> hatch: to go higher than that you need to enable jumbo frames, which you probably do not want to do.
[16:23] <hatch> 50MB/s is the max?
[16:23] <jrwren> hatch: with a 1500byte MTU, yes.
[16:24] <hatch> well what the deuce 
[16:24] <hatch> Do you know how long it takes to back up 100GB at 50MB\s
[16:24] <hatch> long time!
[16:24] <hatch> that's how long
[16:26] <jrwren> hatch: there is a pretty bad discussion about it here: http://arstechnica.com/civis/viewtopic.php?t=343089
[16:28] <hatch> so basically I'm SOL if I want anything faster :)
[16:29] <hatch> well, I suppose I could buy a thunderbolt equipped NAS and park it beside my laptop
[16:29] <hatch> :)
[16:29] <jrwren> 10gig is getting cheaper.
[16:30] <jrwren> or I could be completely wrong.
[16:30] <hatch> tbh I had no idea that gige was so slow
[16:30] <hatch> no wonder server networks are all fiber
[16:30] <jrwren> its gigabit, not gigabyte.
[16:31] <jrwren> you are getting about 50% of that, because your default MTU is 1500
[16:31] <jrwren> gigE supports going to 9k MTU.
[16:31] <hatch> right but that's huge
[16:31] <jrwren> IME server networks aren't all fiber.
[16:31] <hatch> heh
[16:31] <jrwren> the server networks can run 9k MTU though.
[16:32] <hatch> is it still TCP? So it would do the ramp up to 9k?
[16:32] <jrwren> no, that is ethernet MTU
[16:32] <hatch> intersting....
[16:33] <hatch> so what are the downsides to increasing the MTU? Some things may not support it?
[16:34] <hatch> kadams54: I can't find any reason why the service items unhide when pan'd
[16:36] <hatch> this stuff is very opaque with everything being controlled by events firing everywhere heh
[16:37] <hatch> kadams54: there is a bug when you try and hide/highlight a ghost service - is this known?
[16:38] <hatch> Uncaught TypeError: Cannot set property 'highlighted' of undefined service.js:1439
[16:39] <hatch> annnd now I have found why it's being shown again :)
[16:59] <jrwren> hatch: your rather has to be able to fragment packets, which ipv6 doesn't allow, so anything ipv6 will be broken.  your inet router presumably is not gigabit, and so supports MTU of 1500, and that ends up as a lot of fragments, which slows things down.
[16:59] <jrwren> hatch: fragment reassembly is expensive.
[16:59] <jrwren> hatch: it may be worth cautiously playing with :)
[17:00] <kadams54> hatch: a bug on highlighting a ghosted service is new to me.
[17:00] <hatch> lol 
[17:00] <hatch> maybe
[17:00] <hatch> kadams54: ok I'll file it
[17:05] <hatch> kadams54: https://bugs.launchpad.net/juju-gui/+bug/1384819
[17:05] <mup> Bug #1384819: Hiding ghost services throws console error <juju-gui:New> <https://launchpad.net/bugs/1384819>
[17:05] <rick_h_> hatch: feel free to triage that as high and add a card for it
[17:06] <hatch> doing
[17:08] <rick_h_> ty much
[17:13] <kadams54> hatch: test added and findUnrelatedServices moved. I rebased before pushing and then realized I should not have, so sorry about that.
[17:14] <hatch> s'ok i'll take a look
[17:26] <hatch> odd my ubuntu clock is accurate today
[17:29] <hatch> kadams54: one comment
[17:29] <hatch> just thought of it reading your tests
[17:31] <kadams54> I don't know what peer relations are?
[17:32] <kadams54> How this handles different types of relationships (subordinate and otherwise) probably depends on how getRelationDataForService handles them.
[17:32] <kadams54> If it reports them as a related service, then they will be excluded from the set of unrelated services.
[17:33] <hatch> hmm
[17:33] <hatch> a peer relation is essentially a relation between itself
[17:34] <hatch> then there are subordinate relations
[17:34] <hatch> which I think work as expected....
[17:34] <hatch> we should definitely add these relation types to that test
[17:34] <hatch> just to be safe
[17:41] <hatch> I have somehow made my irc client go fullscreen and I can't get out of it
[17:41] <rick_h_> lol
[17:41] <jcw4> hatch: I think quassel has bugs around full screen
[17:42] <hatch> yeah...hmm
[17:42] <hatch> I can't even close it lol
[17:42] <jcw4> I kept crashing or getting it stuck so I quit using f11
[17:42] <jcw4> teh suk
[17:45] <jcw4> hatch: the additional bummer is even if you kill it it may start in full screen again because of preferences
[17:45] <hatch> well here is to hoping I don't do THAT again
[17:45] <hatch> yeah I got lucky
[17:45] <hatch> I was worried about that
[17:46] <hatch> kadams54: so I don't know off hand what the syntax for peer or subordinate relations are - so you might want to deploy wordpress to get the peer relation data
[17:46] <hatch> and I think nagios has a subordinate charm
[17:46] <hatch> so you could do that one for that data
[17:47] <hatch> I wish there was a Textual for Ubuntu
[17:47] <hatch> Textual is a killer IRC client
[17:50] <jcw4> Textual is my favourite too... I just like quassel because I have quassel core running on an always-on ec2 instance so I don't lose history
[17:52] <hatch> yeah Textual has deep ZNC integration
[17:52] <hatch> but it doesn't run on Ubuntu
[17:52] <hatch> :)
[17:58] <kadams54> hatch: do you think that's relevant to the function being tested?
[17:58] <kadams54> Seems like it would be more appropriate in tests for getRelationDataForService
[17:58] <hatch> well that function needs to work properly to return the unrelated services - if it's returning unrelated that are actually related 
[17:59] <hatch> well no the getRelationData method returns the relation data
[17:59] <hatch> at least as I understand it
[18:00] <hatch> technically it's returning all 'related' services then it's up to something else to act on that
[18:00] <kadams54> Ah, so you think the data for a peer or subordinte relation would not be structured as { far: { service: 'foobar'}}
[18:00] <hatch> I'm not sure tbh :)
[18:01] <hatch> it just came to mind while reading the test
[18:01] <kadams54> I thought your concern was that the set of related services might not include everything it should.
[18:01] <hatch> I would hate if a subordinate wasn't hidden (or was) when it wasn't suppsoed to be
[18:01] <kadams54> But it sounds like that's not right; what you're actually worried about is that the data in that set could look different for different types of relationships. Is that correct?
[18:02] <hatch> right
[18:02] <kadams54> I'll verify
[18:02] <hatch> if you're filtering on 'far' but 'subordinate' is still shown
[18:02] <hatch> then that'll be a UI bug
[18:02] <hatch> but not sure if that's a real issue :)
[18:05] <hatch> thanks for looking into it'
[18:05] <hatch> I know know where the canvas bugs are comign from but still groking how best to fix
[18:19] <hatch> lunching
[19:05] <kadams54> hatch: verified that subordinate and peer relationships use the same data structure.
[19:13] <hatch> kadams54: awesome thanks
[19:19] <kadams54> hatch: you a +1 to land that?
[19:19] <hatch> oh yeah
[19:19] <hatch> :)
[19:19] <hatch> sorry
[20:02] <urulama> nice to see CS surviving floods of icon requests :D
[20:03] <rick_h_> :)
[20:03] <hatch> moar pichures
[20:04] <urulama> :D :D
[20:18] <hatch> rick_h_: jcsackett do you guys know if I can install GUI'd applications in an lxc?
[20:18] <rick_h_> huh?
[20:19] <rick_h_> what's a GUI'd application?
[20:19] <hatch> well anything with a GUI, say Eclipse IDE
[20:19] <urulama> hatch: ssh -X ?
[20:19] <hatch> or sublime, etc
[20:19] <rick_h_> yea, probably have to do X forwarding/etc but sure
[20:19] <rick_h_> hatch: I think serge had a blog post on doing that
[20:19] <rick_h_> https://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/ 
[20:19] <hatch> essentially I'm wondering if I could create a charm for developing with dart which would include the ide and such
[20:19] <rick_h_> hatch: ^
[20:20] <hatch> ahh excellent
[20:20] <hatch> yet another weekend project that may or may not get started on :)
[20:21] <hatch> it would be super awesome to juju bootstrap local; juju deploy dart-dev-env :)
[20:21] <hatch> I'm just using dart as an example - this could be very helpful for many different dev envuironments
[22:05] <huwshimi> Morning
[22:05] <hatch> yooooo
[22:57] <rick_h_> huwshimi: morning 
[22:58] <rick_h_> huwshimi: hatch sorry, doing dishes and lost track of time
[22:58] <huwshimi> rick_h_: Hey, no problems
[22:58] <rick_h_> hatch: did you need to do weekly call?
[22:58] <rick_h_> huwshimi: let's just meet there in case he wants to jump in
[23:00] <rick_h_> https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.dd77sn7kjl6unba21lutdr0p70?authuser=1
[23:00] <huwshimi> rick_h_: Yep, just joined
[23:00] <huwshimi> oh
[23:00] <huwshimi> joinoing
[23:25] <huwshimi> rick_h_: The issue from Maddison's branch is actually an issue already on trunk, so I might just ship his branch and then do a tiny followup branch to fix the issue. Sound OK?
[23:26] <rick_h_> huwshimi: rgr
[23:26] <rick_h_> huwshimi: thanks!
[23:29] <huwshimi> rick_h_: np, thank you!