[01:53] <hatch> jcsackett ahh thanks
[01:54] <hatch> huwshimi so any luck tackling it on your own?
[01:54] <huwshimi> hatch: I didn't mange to figure out anything yesterday :(
[01:55] <hatch> ok cool, I'll take a look
[01:56] <huwshimi> thanks heaps
[01:56] <hatch> huwshimi what if you include the juju-templates?
[01:56] <hatch> asically the error is because it can't find the element in the dom
[01:58] <huwshimi> I'll try
[01:59] <huwshimi> hatch: No change
[02:00] <hatch> blarg
[02:01] <hatch> ok I've pulled it down
[02:01] <hatch> will investimagate
[02:02] <huwshimi> hatch: Feel free to leave it to your work day, I have plenty to go on with.
[02:12] <hatch> huwshimi it's because it's rendering without the mv flag
[02:12] <hatch> it's rendering the old scaleup UI
[02:12] <hatch> if you put a debugger in the method that's failing and inspect the innerHTML of the container you can see this
[02:13] <huwshimi> Oh
[02:14] <hatch> huwshimi that's because the createServiceInspector method is no longer how we render the inspectors while under mv
[02:14] <hatch> so this is actually testing a path which is no longer valid
[02:15] <hatch> so really - the proper fix is to fix the way inspectors are rendered
[02:15] <hatch> for tests
[02:16] <hatch> but you may be able to hax around it by setting the mv flag and doing some other bits
[02:27] <huwshimi> yep, trying
[02:59] <hatch> huwshimi any luck?
[03:02] <huwshimi> hatch: Just having some lunch...
[03:02] <hatch> ok cool, I think I'm gona head and watch some tv, if you can't get it just leave the PR and I'll take a look in the am
[03:04] <hatch> have a good one
[07:21] <rogpeppe> urulama: morning!
[07:21] <urulama> rogpeppe: hey there
[07:22] <urulama> rogpeppe: how's it going? 
[07:23] <huwshimi> rogpeppe, urulama: Morning
[07:23] <rogpeppe> urulama: not bad thanks
[07:23] <urulama> rogpeppe: i'm trying to finish the "sprint summary" document so that i can move forward with the implementation part, but it's taking tiiiiime :)
[07:23] <rogpeppe> urulama: have you recovered from last week yet?
[07:23] <urulama> huwshimi: good evening ;)
[07:23] <huwshimi> :)
[07:23] <urulama> rogpeppe: em ... partly recovered. progress bar at around 33% :)
[07:24] <rogpeppe> urulama: :-)
[07:27] <urulama> rogpeppe: we have a national holiday on Friday, might help to move to 50% :) and it's good to put things on paper as long as they are still in memory
[07:27] <rogpeppe> urulama: definitely
[07:29] <urulama> rogpeppe: i plan to jump on PRs and current implementation around noon (in 2h) ... would that be ok? any open questions or anything until then?
[07:29] <rogpeppe> urulama: no, all's good
[07:30] <urulama> rogpeppe: great to hear ... ok, back to tasks for the next 2 months
[07:32] <urulama> rogpeppe: oh, btw, how far have you and Francesco come regarding uploads?
[07:32] <rogpeppe> urulama: uploads now work
[07:33] <urulama> rogpeppe: as in "zip properly formatted dir" and upload and new charm is in charmstore?
[07:33] <rogpeppe> urulama: and you can now download individual archive files too
[07:33] <rogpeppe> urulama: yup
[07:33] <urulama> \o/
[07:34] <rogpeppe> urulama: ah, the only thing that's not done is that we don't currently verify bundles against the existing charms
[07:35] <urulama> rogpeppe: as in when bundle is uploaded it is not checked wether the charms are in the CS?
[07:35] <rogpeppe> urulama: yes
[07:35] <rogpeppe> urulama: we deliberately left it for a later PR - but it does need doing
[07:36] <rogpeppe> urulama: and there's also something i thought of in bed this morning
[07:36] <rogpeppe> urulama: which is that we can't always start revision numbers from zero
[08:00] <urulama> morning, frankban
[08:00] <frankban> morning urulama 
[08:00] <frankban> urulama: are you able to connect to canonical IRC servers?
[08:00] <urulama> yes
[08:00] <urulama> frankban: but i've seen others being disconnected
[08:00] <frankban> urulama: uhm, ok
[08:01]  * TheMue has troubles too, also with SSO
[08:01] <frankban> urulama: I see "Connection failed. Error: Connection refused"
[08:01] <frankban> will try again later
[08:01] <frankban> switched to zsh, let's see how it works
[08:13] <urulama> frankban: next step acme? :)
[08:15] <frankban> urulama: http://www.nooooooooooooooo.com/
[08:15] <frankban> ;-)
[08:15] <urulama> :) :) :)
[08:16]  * urulama bookmarks the page for future use
[08:38] <urulama> frankban: ok, i have problems with cannonical irc as well, however, it manages to reconnect 
[08:39] <frankban> urulama: ok
[10:45] <frankban> urulama, rogpeppe, jrwren: https://github.com/juju/charmstore/pull/69
[10:46] <urulama> frankban: finishing a doc, then lunch, then PR. ok with you? can move PR first if it is blocking anything else
[10:47] <frankban> urulama: it's ok thanks
[10:56] <rogpeppe> frankban: reviewed
[10:57] <frankban> rogpeppe: thanks
[11:40]  * urulama goes on short lunch
[12:26] <urulama> frankban: the tests currently check mostly if the time is there ... could we create a bit more complex test? starting with a charm revision at time 0, then upload new revision, one in the period T of time? Then, check if all revisions have proper n*T archive-upload time?
[12:29] <frankban> urulama: not sure if I understand. at the store level, we already check that the time is the expected one (in a specified timeframe)
[12:34] <urulama> frankban: suggestion is to have a "possible" reggression test, that adds a charm (addCharm), multiple times, and check proper revisions and timestamps
[12:35] <urulama> frankban: on the api level 
[12:36] <frankban> urulama: so, we publish a charm with the same id two times and we check the id is incremented and t2> t1?
[12:37] <urulama> frankban: yes, maybe also with "sleep" of time T between publishing
[12:37] <frankban> urulama: why sleeping?
[12:41] <rogpeppe> urulama: i don't really see what that test would be adding
[12:41] <rogpeppe> urulama: given that we're testing that the upload time is within a very short period
[12:42] <rogpeppe> urulama: (assuming frankban applies my suggested change)
[12:42] <frankban> rogpeppe: I did
[13:03]  * frankban lunches
[13:10]  * rogpeppe also lunches
[13:36] <bac> ha, this is a nice tool:  http://www.downforeveryoneorjustme.com/lastpass.com
[14:17] <rogpeppe> bac: should be www.downfordownforeveryoneorjustme.com :-)
[14:18] <bac> rogpeppe: i don't get it
[14:18] <rogpeppe> bac: well, really, it would be an infinitely long name
[14:18] <rogpeppe> bac: the point being that it's only that web site that makes the check
[14:19] <bac> rogpeppe: true
[14:19] <rogpeppe> bac: so it could be down for everyone except me and their server
[14:20] <bac> rogpeppe: regardless of the inaccuracy of their naming, it is a nice check, especially when you have reason to believe it is just you.
[14:20] <bac> as i often do
[14:20] <rogpeppe> bac: absolutely. i've found it very useful in the past, although i'd forgotten about it of late
[14:47] <hatch> wb Makyo 
[14:47] <frankban> rogpeppe: I am going to change BulkIncludeHandler to receive a request rather than a method and flags
[14:47] <rogpeppe> frankban: i started off doing that
[14:47] <rogpeppe> frankban: but it didn't work out
[14:47] <frankban> rogpeppe: we need access to req.Body e.g. for the extra info stuff
[14:48] <frankban> rogpeppe: why?
[14:48] <rogpeppe> frankban: really?
[14:48] <frankban> rogpeppe: extra-info PUT 
[14:48] <rogpeppe> frankban: hmm, i guess i thought that stuff would be in the flags, but you're probably right
[14:49] <frankban> rogpeppe: anyway, I'd feel the framework to be more friendly if it gives the request to you anyway
[14:49] <rogpeppe> frankban: the reason it didn't work out was because of Router.GetMetadata
[14:50] <rogpeppe> frankban: and that it seemed wrong to be making up Requests for bulk metadata requests
[14:50] <hatch> jujugui call in 10
[14:50] <rogpeppe> frankban: are you planning to do extra-info ?
[14:50] <rogpeppe> frankban: i was working towards that
[14:51] <frankban> rogpeppe: I was just taking a look at the framework and realized that. If you want to tackle it I'll live it to you
[14:51] <frankban> rogpeppe: I'll look at something else, like verifyWithCharms in publish API
[14:51] <rogpeppe> frankban: i'd be happy to pair on it if you like. i'm wading through mud currently.
[14:52] <frankban> rogpeppe: sounds good
[14:52] <rogpeppe> frankban: cool, let's do that.
[14:52] <rogpeppe> frankban: after the standup?
[14:52] <frankban> rogpeppe: sure
[14:56] <rogpeppe> frankban: BTW, if we used a standard "application/x-www-form-urlencoded" MIME type, then the PUT arguments will end up in the flags argument
[14:56] <rogpeppe> frankban: we don't say much about how the PUT values are encoded in the spec
[14:57] <urulama> rogpeppe: good point, we dont
[14:58] <hatch> jujugui anyone else getting "party is over" error?
[14:58] <rogpeppe> hatch: yup
[14:58] <hatch> worked now
[14:58] <hatch> just keep trying I guess
[14:58] <hatch> heh
[14:59] <rogpeppe> urulama, frankban: we could standardise on using a single form attribute, say "value" containing the JSON-encoded value to PUT.
[15:00] <frankban> rogpeppe: It's doable, still not sure if I like it over just sending the json in the body
[15:02] <jrwren> "It's taking too long to connect you to this video call. Try again in a few minutes."
[15:02] <urulama> jrwren: daily standup :)
[15:02] <jrwren> "please wait..>"
[15:15] <frankban> rogpeppe: gogogo in 5
[15:15] <rogpeppe> frankban: ok
[15:15] <rogpeppe> frankban: i'm there, BTW
[16:01] <hatch> man somethin is munchin on my internets
[16:05] <jcsackett> hatch: this is the second day, if we're going by your sign on/sign off.
[16:05] <hatch> yeah it is :/ 
[16:06] <hatch> good thing I don't pay for QOS
[16:06] <hatch> oh wait....
[16:09] <hatch> rogpeppe your card that's in landing....is it still landing or blocked? Maybe it should be moved into tracking?
[16:10] <rogpeppe> hatch: i'm trying to land it but it's blocked
[16:10] <rogpeppe> hatch: if tracking is a better place for that, then by all means move it there
[16:11] <hatch> rogpeppe yeah I think that lane is for actively landing....whereas yours might sit there for a week? :)
[16:23] <kadams54> hatch: completely befuddled on this test I'm trying to fix. Ping me when you have a few moments.
[16:23] <hatch> kadams54 you're in luck I just finished a review
[16:23] <hatch> what's up?
[16:25] <kadams54> this is the currently breaking code: https://github.com/juju/juju-gui/blob/develop/app/widgets/deployer-bar.js#L257
[16:25] <kadams54> It loops through a set of keys and checks to see if any of their values have a length.
[16:26] <hatch> ok
[16:28] <hatch> is there more to this story?
[16:28] <hatch> :)
[16:28] <kadams54> The problem is that my code adds a new key who's property is an int
[16:28] <kadams54> So I thought I'd just add an Array.isArray check before we look at length
[16:28] <kadams54> It's false, but hasChange is still getting set to true
[16:29] <hatch> ok looking
[16:30] <kadams54> Should I push my changes up so you can see them?
[16:30] <kadams54> Or would you prefer something like a gist?
[16:32] <hatch> well I'm just trying to figure out what this is doing
[16:32] <kadams54> This screenshot pretty much summarizes my confusion: http://cl.ly/image/20132A2e051Z
[16:33] <kadams54> Both conditions for the if statement eval to false, yet we're inside and hasChange is set to true.
[16:35] <hatch> that might be an issue with how watches are evaluated
[16:35] <hatch> what if you run those in the console?
[16:36] <hatch> and you'll want to use Y.Array.isArray() I'm not sure if Array.isArray() is supported everywhere yet
[16:36] <hatch> what is this even testing for? What makes it a major change? If any of the objects have something in them then major change is true?
[16:40] <jcsackett> thanks for the review, Makyo. :)
[16:41] <kadams54> hatch: we're using an object as a hash here. The original code makes an assumption that all the values in the hash are arrays of changes. If any of the arrays have a non-zero length, then we have major changes and need to display the summary panel in addition to the changelog.
[16:42] <hatch> ok but that basically means that if there is anything in changes then we need to show it...what tasks aren't shown?
[16:42] <hatch> what I'm getting at is this method isn't necessary
[16:42] <hatch> because if you do anything it will return true
[16:42] <hatch> if any of the changes keys have values it's true
[16:44] <jcsackett> jujugui: i need 2 reviews on this (very short) PR. https://github.com/juju/juju-gui/pull/491
[16:44] <kadams54> But not all of the keys in the hash are arrays of changes.
[16:44] <hatch> jcsackett no test? :)
[16:45] <jcsackett> hatch: nope--there's no meaningful way to get in and test the d3 logic.
[16:45] <hatch> kadams54 right - but what I'm saying is that this method is causing you issues.....I don't think this method is necessary because if there is anything in the changes object then it's shown
[16:45] <jcsackett> i can break out the logic about what to show into a separate method and test that, if you like.
[16:45] <kadams54> hatch: not necessarily the case.
[16:45] <hatch> jcsackett well that's just not true :) we test the unit list somewhere
[16:45] <hatch> kadams54 ok what is the case where it isn't?
[16:46] <kadams54> hatch: for example, if the user just adds a container, we only show the changelog. We don't show the summary panel.
[16:46] <jcsackett> hatch: we set up some stuff using the generateAndBind, but we don't inspect those contents.
[16:46] <kadams54> In that case, all of the arrays in the changes hash would have a 0 length.
[16:46] <kadams54> i.e., no "major" changes
[16:46] <jcsackett> hatch: which is reasonable, b/c it's just testing "does d3 set an a tag when i tell it to set an a tag.
[16:47] <jcsackett> hatch: as i said, if you like i can break that change out into a "chooseDisplayName" method for units, and test *that*.
[16:47] <hatch> jcsackett I'm pretty sure we have a test which renders the unit list and then checks the dom to make sure there are x number of units rendered 
[16:47] <hatch> maybe inspector overview or something
[16:48] <hatch> kadams54 ok and you have added something to changes.addUnits?
[16:48] <kadams54> Yeah… totalUnits…
[16:48] <jcsackett> hatch: that's where i looked. unless you
[16:48] <kadams54> Which is an int
[16:48] <jcsackett> hatch: unless you're talking the scale out tests, which arne't qute the same kettle of fish.
[16:50] <kadams54> hatch: sorry, I didn't add anything to changes.addUnits. I added it to changes. So changes now has changes.addUnits and changes.totalUnits.
[16:50] <hatch> kadams54 ok so you could have getChanges return an object where one property is the changes and the other is the total units
[16:50] <hatch> then you don't have to modify this method
[16:51] <hatch> which is what I would recommend because your putting stuff in the changes property that doesn't really fit with the rest of the dataset 
[16:51] <kadams54> OK, will do
[16:51] <hatch> sounds good?
[16:51] <hatch> ok cool
[16:52] <hatch> jcsackett I'm just saying it would be nice if we could test that when we pass an uncommitted model into the d3 stuff it renders the proper name 
[16:52] <hatch> and the other way 
[16:53] <hatch> it was what the bug was about afterall
[16:53] <jcsackett> hatch: i'm not disagreeing, but the test for that will be ridiculous. like i said, i can break out the logic part of it into another method, and test that it returns the right thing; after that it's a matter of believing d3 does the right thing or not.
[16:53] <hatch> I'll try and find the test
[16:53] <hatch> you may be able to copy it
[16:53] <hatch> one sec
[16:53] <hatch> but I agree if you have to write it all
[16:53] <hatch> no good :)
[16:54] <jcsackett> i'm reading through inspector_overview and not seeing anything that looks right.
[16:56] <hatch> jcsackett test_inspector_overview.js:477
[16:56] <hatch> the test is massive but  you can likely modify it to use one uncommitted unit model as well as the regular others
[16:56] <hatch> or add another unit to the list 
[16:57] <jcsackett> hatch: i'll see--i don't think the return from that is quite right to see what's rendered in the lists, but you might be right.
[16:57] <jcsackett> oh, i see, it's dumping the whole damn mess.
[16:57] <jcsackett> ok.
[16:58] <hatch> so you should be able to just add an uncommitted unit to this and test that that unit is rendered properly and that another one is rendered property too
[17:09]  * rogpeppe is done for the day
[17:09] <rogpeppe> g'night all
[17:09] <jcsackett> hatch: done.
[17:10] <jcsackett> thanks for helping sort out where to test it; that block is impenetrable when you're scanning without being certain what you're looking for. :p
[17:11] <hatch> haha yeah it is np
[17:11] <hatch> ok will qa
[17:11] <hatch> jcsackett lint error
[17:11] <hatch> lol
[17:12] <hatch> we should make a rule - if your tests fail with a lint error you got to buy everyone a coffee :P
[17:13] <jcsackett> i honestly am not sure of the utility of lint being run on every test--on merge, sure, but it's just noise to me.
[17:14] <hatch> I always run the full suite before pushing - and now that I'm in Ubuntu the tests don't fail randomly lol
[17:15] <jcsackett> hatch: i always run the tests; i don't always run check.
[17:15] <hatch> oh right cuz it's really slow for you isn't it?
[17:15] <jcsackett> hatch: sufficiently slow.
[17:16] <jcsackett> slow enough that i end up waiting a while, not long enough to do anything meaningful while it runs.
[17:19] <hatch> time for an ssd?
[17:29] <kadams54> hatch: looks like huw needs second reviews on a couple PRs?
[17:30] <hatch> kadams54 the x uncommitted one I need to write the fix for it to get it to land
[17:30] <hatch> but the mv scale up one does
[17:30] <hatch> is yours all good to go?
[17:31] <hatch> looks good
[17:31] <hatch> once the tests pass you can land it
[17:31] <kadams54> Yeah
[17:31] <kadams54> I was noticing we had a build-up of cards in review
[17:32] <kadams54> I'll dig into the mv scale up one.
[17:34] <kadams54> Looks like the scale up one needs to be rebased and have some conflicts resolved
[19:06] <hatch> telcos should have a flag on peoples accounts which mark their level of expertise
[19:07] <hatch> so when you call with a problem they don't ask you if you have restarted your router and make you do it again for kicks
[19:09] <hatch> jcsackett can you rebase your branch and shippit?
[19:10] <hatch> #491 that is
[19:19] <jrwren> I actually called Comcast once after I did some basic troubleshooting. I had forgot to reset my cable modem. 
[19:19] <jrwren> The support person saying "Turn it off and back on again" actually solved my problem.
[19:20] <hatch> lol
[19:30] <urulama-afk> jrwren: config-changed error: http://pastebin.ubuntu.com/8029262/
[19:32] <urulama-afk> jrwren: relations in charms: http://pastebin.ubuntu.com/8029269/
[19:33] <jrwren> urulama-afk: that doesn't look like an error. :(
[19:34] <urulama-afk> error: no relation id specified
[19:34] <urulama-afk> maybe it's enough to trigger the hooks and to leave the charm in "installed" but not "started" state
[19:35] <jrwren> urulama-afk: I'll try to reproduce. Thanks.
[19:36] <jrwren> urulama-afk: I'm still new enough to charming that I don't remember all this stuff. I can't recall if that error: is valid or not.
[19:36] <urulama-afk> jrwren: me and you both :)
[19:36] <jrwren> jrwren: Still, and invalid error message is a bug, so I'll fix it.
[19:36] <jrwren> s/and/an/
[19:37] <urulama-afk> jrwren: yes, i can exit the tmux and then the status is "started"
[19:37] <jrwren> urulama-afk: can you curl that ip on the listen port?
[19:41] <urulama-afk> jrwren: it gets stuck on most of the hook scripts, but running them manually and exiting tmux produces service in a "started" state, and curl works
[19:42] <jrwren> hrm. it gets stuck and you have to resolved --retry?
[19:42] <urulama-afk> jrwren: i mean, the CS is empty, but there are "error" codes to show that it works
[19:42] <jrwren> urulama-afk: that is VERY weird.
[19:43] <jrwren> urulama-afk: Empty and responsive is my goal.
[19:43] <urulama> jrwren: i haven't tried deploying without debug-hooks, let me add another unit, it might just as well work
[19:49] <urulama> jrwren: indeed ... seems like debug-hooks interpret your error messages as true errors ... without them, the charm starts and is in "started" mode
[19:50] <jrwren> urulama: Good, that is what I thought.
[19:50] <hatch> you guys ok with all this? I've done some charm work, can maybe offer some input
[19:51] <hatch> jcsackett thanks
[19:51] <urulama> jrwren: ok, so fixing that is simple, just changing error to "warning" or something, as they are not true errors
[19:51] <urulama> hatch: thx
[19:51] <jcsackett> hatch: no worries; hadn't noticed i had all my reviews for it. :)
[19:51] <jcsackett> thanks for pinging me.
[19:51] <jrwren> urulama: its charmhelpers.
[19:52] <urulama> jrwren: khm. then it might not be that innocent after all :) 
[19:52] <jrwren> hatch: What is the right way to use charmhelpers.core.hookenv.relation_get ?
[19:53] <hatch> what's this python mumbo jumbo...I just shell out to the real relation get
[19:53] <hatch> https://github.com/hatched/ghost-charm/blob/master/hooks/db-relation-changed
[19:54] <hatch> so sorry, I have never used charmhelpers :)
[19:54] <jrwren> hatch: I'm pretty sure I was told to use this.
[19:54] <hatch> yeah you likely were
[19:54] <hatch> sometimes the abstraction is more work though
[19:54] <hatch> case-and-point :)
[19:54] <jrwren> hatch: Are you sure it is only sometimes? :)
[19:55] <hatch> haha
[19:55] <hatch> jrwren you'll probably have some luck asking in #Juju-dev
[19:56] <urulama> hatch: do not lead jrwren into temptations! :)
[19:57] <jrwren> It is likely as simple as if not relation_ids(): before those relation_get calls'
[19:57] <hatch> urulama haha sorry - I've written charms in node and bash, and fixed the gui one which is in python so never really used charmhelpers and the like
[20:03] <urulama> hatch: i deploy charms from CLI, that doesn't mean GUI is useless :D
[20:04] <hatch> urulama definitely not, after about the 1000th time of writing `juju set some-really-big-charm-name some-really-big-config-name="some really long value"` you'll just use quickstart and use the GUI exclusively 
[20:04] <hatch> lol
[20:05] <urulama> :D :D
[20:06] <urulama> ok, time to really EOD ... see you all tomorrow, jujugui (and irc clients go 'ping' all over the globe)
[20:06] <bac> later urulama
[20:06] <jrwren> urulama: good night. TY.
[20:06] <hatch> haha cya urulama 
[20:42] <rick_h__> jrwren: ask in #juju of marcoceppi or mbruzek around that. Maybe tvansteenburgh as well. They work on and maintain the charmhelpers
[20:42] <rick_h__> hatch: helps us use/make better our own tools :P
[20:43] <marcoceppi> o/
[20:43] <hatch> rick_h__ I'm not sure anything that's 3 levels deep for a simple shell-out call is a valid abstraction :D
[20:43] <rick_h__> hatch: time to make it better? 
[20:43] <rick_h__> hatch: shell out with proper catching of return values, logging integration, etc can be worth it
[20:43] <rick_h__> however I have a lack of context in this matter so I wave my hands around in a general fashion
[20:43] <hatch> honestly I have no idea what it does under the hood, never used it :) 
[20:44] <mbruzek> ask me what?
[20:44] <rick_h__> mbruzek: jrwren is having some issues with relation-get and charmhelpers or the like
[20:44] <rick_h__> mbruzek: just volunteering you for support of jrwren gets stuck :)
[20:44]  * mbruzek nods
[20:47] <hatch> maybe I should write a charm in python to learn about these helpers-of-the-charm
[20:51] <marcoceppi> hatch: ALL HAIL THE HELPERS OF THE CHARM
[20:51] <jrwren> hatch: If you are a cranky programmer like me, it might just annoy you that it isn't in bash. ;]
[20:52] <hatch> jrwren bash MAKES a cranky programmer
[20:52] <hatch> marcoceppi lol
[20:52] <hatch> rick_h__ you still around?
[20:52]  * jrwren uses /dev/tcp in bash instead of curl 
[20:52] <hatch> lol
[20:54] <hatch> jcsackett Makyo kadams54 want to weigh in on https://github.com/juju/juju-gui/pull/486#issuecomment-51975411 ? 
[20:54] <rick_h__> hatch: sure
[20:55] <rick_h__> hatch: packing up, flight home in the morn
[20:55] <hatch> rick_h__ want to weigh in on that? ^
[20:55] <kadams54> hatch: lgtm
[20:55] <rick_h__> hatch: looking
[20:56] <rick_h__> hatch: "update a template which doesn't exist" ?
[20:57] <hatch> rick_h__ the real issue is that it's not the template which doesn't exist, it's that it's using the old inspector rendering code
[20:57] <hatch> so we have to write a new test mock for generating the inspector to use the NEW mv style inspector rendering code
[20:57] <hatch> which has to be done anyways but will block this branch 
[20:58] <rick_h__> hatch: that seems like something we'll need anyway? (a new helper for generating a new inspector)
[20:58] <rick_h__> hatch: ok, but this comment is about waiting until MV is released, not about a missing test helper?
[20:58] <rick_h__> nothing here is documenting/adding that we need the helper as the 'right' fix?
[20:58] <hatch> yeah sorry that wasn't clear
[20:58] <rick_h__> or am I mis-reading that?
[20:59]  * rick_h__ loads up kanban
[20:59] <hatch> so this branch either needs to wait until the new inspector mock test thingy is written or apply the included patch to land it now
[21:00] <hatch> I gather the new inspector mock thingy will take 1day and then moving all the tests to use it will be....2?
[21:00] <rick_h__> hatch: ok, I'm cool with the patch with a proper XXX, documenting the place the needs updating, and a follow up card at the top of the lane
[21:01] <hatch> ok I'll work on the inspector thingy, I added a friday card to chat about it
[21:01] <hatch> thx
[21:01] <rick_h__> hatch: coolio, thanks. 
[21:01] <hatch> safe travels!
[21:02] <rick_h__> wheeeee
[21:02] <rick_h__> can't wait to have my own pillows again
[21:02] <hatch> lol
[21:02] <hatch> it's the small things, right?
[21:03] <rick_h__> you know it
[21:03] <rick_h__> like AC that works
[21:03] <rick_h__> getting sick of always sweating in EU
[21:03] <hatch> haha, I never would have thought that would be an issue
[21:04] <rick_h__> us norhern folks don't like it so hot, my basement office is calling me
[21:05] <hatch> haha
[21:05] <hatch> I'm with you on that one!
[21:15] <hatch> Makyo good choice in cards :)
[21:15] <rick_h__> well I'm out, have fun all. See you soon. 
[21:15] <hatch> cya rick_h__  safe travels
[22:06] <hatch> jujugui lf a review (no qa) https://github.com/juju/juju-gui/pull/492
[23:03] <huwshimi> Morning
[23:21] <hatch> morning huwshimi 
[23:24] <hatch> huwshimi all reviews are done and comments made so you should be able to land both of your branches
[23:24] <hatch> today
[23:24] <hatch> and if you could also do a quick review on mine that would be great because mine provides the hooks you will need to mark up the UI with the 'deleted' attributes
[23:24] <hatch> ^ huwshimi 
[23:25] <jrwren> huwshimi: Good morning.
[23:34] <jrwren> My wife and child just reminded me that today is my last day living at the age of 36 years old.
[23:35] <hatch> WHAAAAA
[23:35] <hatch> I thought you were like.......26
[23:35] <hatch> lol
[23:36] <jrwren> Whaaa???
[23:36] <hatch> haha yeah
[23:41] <huwshimi> hatch: Yep no problems, just doing a little qa
[23:52] <huwshimi> hatch: So to use that flag would we have to update this to use lazyDestroyMachines? https://github.com/juju/juju-gui/blob/develop/app/widgets/machine-view-panel.js#L710