[00:02] <huwshimi> hatch: Just wondering if you know how the ambiguous relation menu is supposed to look?
[00:38] <hatch> huwshimi: hey - it's supposed to look better
[00:38] <hatch> :)
[00:39] <huwshimi> hatch: OK, better :)
[00:39] <hatch> yeah there are no mockups so just better :)
[00:41] <huwshimi> alrighty then
[02:46] <kadams54> hatch: I saw the PR of all PRs finally landed.
[14:32] <hatch> jujugui lf a review and qa on removing the as flag https://github.com/juju/juju-gui/pull/643 
[14:32] <jcsackett> hatch: looking now.
[14:32] <hatch> thanks
[14:41] <hatch> jujugui need one more review for ^
[14:42] <kadams54> hatch: looking
[14:42] <hatch> thanks
[14:42] <hatch> rick_h_: are you ok with the flag removal landing? 
[14:43] <rick_h_> hatch: is it ready? :)
[14:43] <rick_h_> hatch: yea, I need to find time to get over to the GUI side and QA and such. Will try to do that once we get the release going today
[14:43] <hatch> well there is one known bug - so i'd like to get the flag removed so we can catch any related bugs while doing the remaining work
[14:44] <rick_h_> hatch: rgr
[14:44] <hatch> there were so many mv related bugs after removing the flag that I want to avoid that
[14:44] <kadams54> hatch: what's the one known bug?
[14:44]  * kadams54 really hopes it's the card he's working on.
[14:45] <hatch> kadams54:  it's theorange card in this project
[14:45] <hatch> about the toggling of the highlight button
[14:47] <hatch> kadams54: is that the one you are working on? I was just about to grab it
[14:47] <kadams54> No
[14:47] <hatch> ok taking
[14:48] <kadams54> But I disagree  with the card that unhighlight needs to be changed to method calls
[14:48] <hatch> Huw did a great job styling the ambiguous relation dialog last night
[14:48] <kadams54> Or rather, I'm highly skeptical ;-)
[14:48] <rick_h_> because huw is awesome :)
[14:48] <hatch> haha he is
[14:48] <hatch> kadams54: yeah first I need to figure out why it only is an issue with ghost services and not deployed ones
[14:48] <hatch> then will figure out an appropriate fix
[14:48] <kadams54> Good stuff - looking forward to seeing it in action
[15:17] <marcoceppi> for manage.jujucharms.com, I only get 20 results back everytime I search which makes queries like type=approved&series=trusty worthless
[15:18] <rick_h_> marcoceppi: &limit=1000?
[15:18] <marcoceppi> changes nothing
[15:19] <hatch> kadams54: fixed it 
[15:19] <hatch> without changing it to a method
[15:19] <hatch> just going to write the test now and then I'll have it up
[15:19] <kadams54> hatch: sweet. What needed fixing?
[15:19] <rick_h_> marcoceppi: looking
[15:20] <kadams54> Sign me up for QA and review :-)
[15:20] <hatch> heh will do
[15:20] <hatch> you were on the right track with your fix but looking the wrong direction ;)
[15:22] <hatch> now the question is...does it work with relations
[15:23] <kadams54> And does it work with machine view
[15:23] <hatch> *snif* it does *snif* it's...so....beautiful
[15:23] <kadams54> And does it work when you turn highlight on for one service and hide 3 other services, two of which aren't related at all to the highlighted one.
[15:24] <kadams54> And does it work when you go in the reverse direction
[15:24] <kadams54> kadams54: snap out of it! *slap*
[15:24] <kadams54> kadams54: Thanks, I needed that.
[15:24] <hatch> yep everything is good - but ghosted services don't hide properly in the machine views
[15:24] <hatch> I'll make a card for that for you
[15:25] <kadams54> *sob*
[15:25] <kadams54> It took us a week to implement 90% of added services.
[15:25] <hatch> hah - well you know the mv stuff the best
[15:26] <kadams54> And then someone *ahem* said, "hey, could we tweak how this works?" And bam, three weeks later.
[15:26] <hatch> yeah but it's stable now 
[15:26] <hatch> :)
[15:26] <rick_h_> marcoceppi: ugh, not sure man. We've not landed any new code there in forever but yes, all queries are maxing out at 20 results. 
[15:26] <marcoceppi> \o/
[15:27] <marcoceppi> cool, well that's fine for now I just won't mess with charm-tools for a bit
[15:27] <rick_h_> marcoceppi: https://api.jujucharms.com/v4/search?series=trusty&limit=600 
[15:27] <marcoceppi> :OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOo
[15:27] <rick_h_> if you need some info right now the new api has it working
[15:27] <marcoceppi> ITS SO FAST
[15:27] <rick_h_> :) only the ids returned
[15:27] <rick_h_> but yea, much faster 
[15:27] <rick_h_> marcoceppi: but don't rely on this yet. It's still early and the url is going to change/etc
[15:27] <marcoceppi> also, whats the way to get just approved
[15:27] <marcoceppi> or promulgated or whatever
[15:28] <marcoceppi> too late, already dependant on it
[15:28] <rick_h_> marcoceppi: but can help https://api.jujucharms.com/v4/search?series=trusty&owner=&limit=600
[15:28] <rick_h_> marcoceppi: setting owner= (empty) will show approved
[15:28] <marcoceppi> \o/
[15:28] <hatch> kadams54: are there no tests for the onHighlightToggle methods?
[15:28] <rick_h_> marcoceppi: raising a bug on charmworld and will see. For now let me konw and we can help get you the info needed from the new api endpoint to unblock.
[15:29] <marcoceppi> that unblocks me for now
[15:29] <kadams54> hatch: There should be. One moment…
[15:29] <hatch> ahh they are tested as side effects
[15:29] <marcoceppi> won't put it in the charmtools stuff
[15:30] <kadams54> hatch: test_added_services_view.js, around line 304
[15:30] <kadams54> That tests directly.
[15:32] <hatch> well it doesnt' send any service names
[15:32] <hatch> looks like I'll have to modify the suite so I can test with a ghost service id too
[15:36] <marcoceppi> rick_h_: thanks, here's the bug whenever you guys get time https://bugs.launchpad.net/charmworld/+bug/1390127 no real rush
[15:37] <mup> Bug #1390127: All queries are limited to 20 results regardless of limit parameter <charmworld:New> <https://launchpad.net/bugs/1390127>
[15:37] <rick_h_> marcoceppi: ty
[15:53] <rick_h_> jujugui call in 8 please kanban
[15:56] <hatch> jujugui lf a review and qa https://github.com/juju/juju-gui/pull/645
[15:56] <hatch> kadams54: ^
[15:57] <kadams54> Will look after standup
[15:57] <hatch> hows your branch coming along?
[15:57] <hatch> jcsackett: I'll do the other review on huws branch
[16:19] <hatch> kadams54: your card in the maintenance lane - is it landed?
[16:21] <kadams54> hatch: ah, yeah, missed that
[16:26] <hatch> jcsackett: I'm not able to reproduce this bug any longer - could you give it a try on comingsoon to see if it's indeed fixed? https://bugs.launchpad.net/juju-gui/+bug/1339093
[16:26] <mup> Bug #1339093: Drag and drop failing with syntax error <juju-gui:Triaged> <https://launchpad.net/bugs/1339093>
[16:27] <jcsackett> hatch: looks fixed to me.
[16:27] <hatch> thanks, closing
[16:30] <hatch> jujugui anyone need any reviews?
[16:35] <kadams54> hatch, Makyo: https://github.com/juju/juju-gui/pull/642 is ready for reviews and QA.
[16:36] <hatch> kadams54: you didn't reply to my comment
[16:37] <hatch> actually I'm pretty confused by the override thing too
[16:38] <kadams54> hatch: I just replied to your comment.
[16:38] <kadams54> And I addressed the override thing.
[16:41] <hatch> kadams54: ok so your reply should be in a comment in the code - github is being odd and not showing replies in the code for some reason :/ 
[16:41] <kadams54> I did put a comment in the code… the XXX bit.
[16:41] <hatch> I do't see any comment about the override
[16:41] <kadams54> Oh, by "comment in the code", do you mean on the PR?
[16:41] <kadams54> Or in the code in the code?
[16:41] <hatch> right but that doesn't say why you couldn't use the real property in the template
[16:42] <kadams54> Ah, OK
[16:42] <hatch> and I still don't understand override 
[16:42] <hatch> that api seems very....fragile
[16:42] <kadams54> It is
[16:42] <kadams54> And it's all temporary
[16:43] <kadams54> There needs to be some way to distinguish between renders that happen after a button click and those that happen on initial view render.
[16:43] <kadams54> The override flag does that job.
[16:44] <kadams54> We need to be able to tell, because in one situation (initial render) we want to override the local attributes with the service attributes. In the other (after a button click) we don't want to override.
[16:44] <kadams54> We don't want to override because the service attributes are being set to their new values asynchronously and may actually still be the old values at render time.
[16:45] <kadams54> Which would result in the just-clicked button being rendered as inactive.
[16:45] <kadams54> All of this is way too much for code that is intended to be very short-lived, so I'd rather just stick with the current XXX comment and get a card in for the long-term fix.
[16:47] <hatch> kadams54: ok review done
[16:48] <hatch> rick_h_: I'm going to work on https://bugs.launchpad.net/juju-gui/+bug/1375918 - it might take a while, I have no idea :)
[16:48] <mup> Bug #1375918: units can be created without a service causing cascading failures <juju-gui:Triaged> <https://launchpad.net/bugs/1375918>
[17:00] <hatch> kadams54: maybe I'm doing something wrong but I can't get your branch to qa properly
[17:01] <kadams54> hatch: how so?
[17:01] <hatch> it doesn't work heh
[17:01] <hatch> even after clearing cache and all that
[17:01] <hatch> it's like nothing has changed wrt the button statuses 
[17:01] <hatch> maybe could you try rebasing your branch with develop and checking locally
[17:02] <hatch> possible something landed that broke it?
[17:05] <hatch> frankban: hey are you still in?
[17:05] <frankban> hatch: yes on call
[17:05] <hatch> np ping when you have a moment
[17:05] <kadams54> hatch: Bah, no, I broke it myself in the last commit, the one called "review feedback"
[17:05] <hatch> :) ok lemme know when it's fixed
[17:08] <kadams54> Fixed.
[17:10] <hatch> testing
[17:12] <hatch> kadams54: +1
[17:15] <hatch> does demo.jujucharms.com use a different font than when deployed locally?
[17:16] <hatch> they appear to be the same
[17:19] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1390161
[17:19] <mup> Bug #1390161: demo.jujucharms.com and locally deployed GUI has different weighted fonts <juju-gui:New> <https://launchpad.net/bugs/1390161>
[17:19] <frankban> hatch: what's up?
[17:20] <hatch> frankban: well I'm going to be working on  https://bugs.launchpad.net/juju-gui/+bug/1375918
[17:20] <mup> Bug #1375918: units can be created without a service causing cascading failures <juju-gui:Triaged by hatch> <https://launchpad.net/bugs/1375918>
[17:20] <hatch> so this is the one about creating units using 'new' instead of trying to guess the id
[17:21] <frankban> hatch: ok
[17:21] <hatch> I was just wondering if there were any issues you could forsee using this approach
[17:21] <hatch> I can't htink of anything - the machine view seems to work well with it
[17:21]  * frankban thinks
[17:24] <frankban> hatch: the more I think about it, the more I feel that units and machines are very similar on that perspective. so I don't see problems (excluding the required changes on the ecs)
[17:24] <hatch> yeah this change is going to be substantial for sure
[17:24] <hatch> what I don't want to do is implement it then think of a better approach
[17:24] <hatch> either for units or machins
[17:24] <hatch> machines
[17:25] <hatch> newX is certainly prettier than some random id string
[17:25] <frankban> hatch: we can never know what's the next id assigned to new entities in juju
[17:26] <frankban> hatch: that's why the new prefix succeeded in putting ghost machines under a different namespace, avoiding the clashes we have for units
[17:26] <frankban> hatch: so mysql/new1, wordpress/new2 sounds reasonable and also does not look bad
[17:26] <hatch> true true
[17:27] <hatch> this will all fall apart if juju gets ecs in core
[17:27] <hatch> so I suppose that's not a concern either
[17:28] <frankban> hatch: exactly, once we have more state from juju we can avoid pretending to have a state in the browser
[17:29] <hatch> frankban: ok thanks - I'm now more confident that I can emulate the same approach with units :)
[17:29] <frankban> hatch: yes np
[17:33] <hatch> rick_h_: I think this is a critical regression https://bugs.launchpad.net/juju-gui/+bug/1390165
[17:33] <mup> Bug #1390165: container tokens are not rendered <juju-gui:New> <https://launchpad.net/bugs/1390165>
[17:33] <hatch> it exists in the released version
[17:33] <rick_h_> hatch: rgr, then please start that, I'm afk for a little bit
[17:33] <hatch> will do
[17:54] <hatch> kadams54: I see you have picked up the card I created - were you able to reproduce the issue or do you need more details
[17:54] <hatch> re the ghost service machine token hiding
[17:54] <kadams54> Yeah, I reproduced it
[17:54] <hatch> ok great
[17:54] <hatch> I'm going to grab some lunch
[18:48] <kadams54> hatch: I know why ghost machines aren't being highlighted properly. I just don't know how to fix it.
[18:52] <kadams54> Well, maybe I do.
[18:57] <kadams54> Seems that I do. Yay.
[19:03] <hatch> haha yay
[19:04] <hatch> jujugui need one more review on https://github.com/juju/juju-gui/pull/645
[19:05] <Makyo> jujugui trivial 1 review/qa for https://github.com/juju/juju-gui/pull/646
[19:06] <hatch> sure
[19:06] <kadams54> I'll look at both.
[19:06] <kadams54> Or hatch and I will split.
[19:06] <kadams54> Either way.
[19:06] <hatch> kadams54: he still needs 2
[19:06] <hatch> and I need one that's not him :)
[19:06] <hatch> so yep you'll do both ;)
[19:08] <hatch> +1 Makyo
[19:14] <kadams54> Makyo, hatch: For the trifecta: https://github.com/juju/juju-gui/pull/647
[19:14] <Makyo> On it
[19:14] <hatch> kadams54: interesting...
[19:15] <hatch> kadams54: needs tests
[19:15] <hatch> :)
[19:15] <hatch> might as well start on that now :P
[19:15] <kadams54> hatch: got a merge conflict when trying to pull in your #645
[19:16] <hatch> ahh probably in the tests?
[19:16] <hatch> ok fixing
[19:16] <kadams54> hatch: IIRC, setMVVisibility was tested indirectly. I did verify that all tests passed. That said, having some direct tests would not be a bad idea, but I'd prefer to handle it in a separate card.
[19:17] <hatch> kadams54: right - but there was a bug
[19:17] <hatch> you fixed it
[19:17] <hatch> the tests didn't change
[19:17] <hatch> so the tests were insufficient 
[19:17] <kadams54> Not my fault the original author didn't write any direct tests :-)
[19:17] <hatch> well even the indirect tests are likely insufficient then
[19:18] <kadams54> I agree, I just think that's outside the scope of this card.
[19:20] <hatch> how do you figure?
[19:20] <hatch> you didn't update the tests to test for the failure
[19:20] <hatch> so how can we be sure that the next branch that lands doesn't break it again?
[19:21] <kadams54> It would be one thing if there had been tests originally and I just needed to update them. But since they need to be written from scratch, I feel like it's a big enough chunk of work to justify a separate card.
[19:21] <kadams54> Which I will tackle next.
[19:23] <hatch> I'm pretty sure it's just an extra couple assertions in the browser events test file
[19:24] <hatch> in an existing test
[19:24] <hatch> but if you would like to create a new test suite for the unit tests I suppose that would be more thorough 
[19:24] <kadams54> I'd like to get something pretty thorough wrapped around it.
[19:24] <kadams54> It's a pretty important bit of logic.
[19:25] <kadams54> Especially with that crazy nested looping going on.
[19:26] <hatch> conflict resolved on #645
[19:30] <kadams54> hatch: commented on #645. I'll get to work on a test suite for setMVVisibility.
[19:32] <hatch> kadams54: so I had thought of that initially but was concerned about people modifying the ghost display name then playing with the added services stuff
[19:33] <hatch> tbh I'm not sure it's an issue 
[19:34] <hatch> actually it shouldn't matter because it's in a blocking loop
[19:34] <hatch> will make the change
[19:35] <hatch> afp is a frustrating protocol, if it's not being used it closes the connection
[19:35] <hatch> then doesn't reopen when you try to access
[19:36] <hatch> and unfortunately there is no --keep-alive
[19:43] <kadams54> Why are you dealing with AFP?!?
[19:43] <kadams54> (Unless you mean something other than Apple Filing Protocol.)
[19:43] <hatch> lol
[19:44] <hatch> kadams54: my host os is OSX so in order to properly mount my NAS into OSX I need to use AFP
[19:44] <kadams54> You can't use SMB?
[19:44] <hatch> OSX has huge issues with mounting anything using 'normal' prototcols
[19:44] <kadams54> Apple has had AFP deprecated for years now, though they only started migrating away from it in Mavericks.
[19:45] <kadams54> But still, you're on Yosemite, so you ought to be able to use SMB.
[19:45] <hatch> are you sure you'r enot mixing it up?
[19:45] <kadams54> Pretty sure.
[19:45] <hatch> I moved to AFP in mavericks because other techniques woudln't work
[19:45] <kadams54> And you're sure the problem wasn't PIBKAC?
[19:46] <hatch> I was originally using SSHFS I believe
[19:46] <hatch> which was poorly supported
[19:46] <hatch> NFS etc
[19:47] <hatch> maybe that's fixed and I can stop using this horrible bs
[19:47] <hatch> hah
[19:47] <kadams54> http://appleinsider.com/articles/13/06/11/apple-shifts-from-afp-file-sharing-to-smb2-in-os-x-109-mavericks
[19:48] <hatch> lemme check if my synology supports smb
[19:48] <kadams54> What file system are you using on your NAS?
[19:50] <hatch> ahh just updated it and there is a smb2
[19:50] <hatch> option 
[19:50] <hatch> it's under Windows though
[19:50] <hatch> very odd haha
[19:51] <hatch> well I know what I'm going to be doing later
[20:04] <hatch> kadams54: ok updated
[20:07] <kadams54> +1'd
[20:07] <kadams54> hatch: ^
[20:07] <hatch> word
[20:07] <hatch> Linkin Park is coming to Stoon
[20:07] <hatch> w00t
[20:07] <hatch> too bad they likely won't be playing their first two albums wholesale :)
[20:11] <hatch> kadams54: looks like you can land #647
[20:12] <hatch> then hopefully rick_h_ can do a real deep qa on it all :)
[20:12] <kadams54> I've got this test suite half written, so I'll get that included, just to make you happy hatch :-)
[20:12] <hatch> lol
[20:13] <hatch> I think we have all the functionality hammered out now
[20:13] <hatch> I haven't noticed any bugs since these most recent branches
[20:17] <rick_h_> wheee
[20:27]  * rick_h_ crush qa boom
[20:37] <hatch> haha
[20:38] <hatch> rick_h_: it's going to be probably an hour before all the pending branches land then i'll be ready for qa
[20:38] <hatch> or you could merge them into your local branch if you feel like you want to do it now :)
[20:38] <rick_h_> hatch: all good, I've got broken kid at home so won't be able to go through it well until after he goes to bed
[20:38] <hatch> hah ok np
[20:39] <kadams54> Heading out to grab an early dinner with the family. Will be back in about an hour to land #647.
[20:39] <hatch> coolio
[20:50] <hatch> hmm for some reason the container tokens have a hidden class applid
[20:50] <hatch> applied even
[20:55] <hatch> crap I found another bug
[21:18] <hatch> ok - container bug fixed and pushed to PR
[21:18] <hatch> and new bug created
[21:18] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1390228
[21:18] <mup> Bug #1390228: Hiding services should update container column machine <juju-gui:New> <https://launchpad.net/bugs/1390228>
[21:58] <huwshimi> Morning
[22:26] <rick_h_> hatch: we're going to skip the AU call tonight if that's cool
[22:45] <hatch> yeah np
[22:45] <hatch> sorry i missed the ding
[22:47] <huwshimi> hatch: You didn't miss it, we just started very early :)
[22:56] <rick_h_> go luca go 
[22:57] <huwshimi> :)