[01:22] <rick_h__> huwshimi: howdy
[01:24] <rick_h__> jrwren: bac please make sure to use the approp channel for conversations around projects
[01:26] <huwshimi> rick_h__: Hello!
[01:26] <rick_h__> huwshimi: how goes? 
[01:26] <huwshimi> rick_h__: Good thanks. Trip went well?
[01:27] <rick_h__> yea, little hiccup on the way home, but all ends well
[01:27] <rick_h__> now just very very tired
[01:27] <rick_h__> in the TZ I started the day it's now 3:30am :)
[01:27] <huwshimi> haha, oh dear
[01:28] <rick_h__> anyway, back in town. Will probably stick my nose where it doesn't belong tomorrow. 
[01:28] <rick_h__> but will not be on the AU call/etc
[01:28] <rick_h__> huwshimi: but if you want/need to chat let me know and I'll try to make sure to sync up tomorrow night
[01:28] <huwshimi> rick_h__: No problems. Everything is good at the moment. Plenty to do.
[01:29] <rick_h__> huwshimi: cool, did you get a chance to poke at the 'more menu' at all?
[01:29] <rick_h__> I didn't see anything that looked like it, wanted to check if we've broken ground on that?
[01:29] <huwshimi> rick_h__: I haven't got that yet. I can tackle that next.
[01:29] <rick_h__> huwshimi: ok cool 
[01:29] <huwshimi> rick_h__: Happy for it to be a widget, correct?
[01:30] <rick_h__> huwshimi: yea, I think so
[01:30] <rick_h__> huwshimi: we'll leave it for hatch to find a hole in the logic :P
[01:30] <huwshimi> rick_h__: hehe, no problems.
[01:30] <hatch> blarg
[01:31] <huwshimi> hehe
[01:37] <hatch> I'd vote to remove everything widget :)
[01:38] <rick_h__> hatch: and when I'm less tired we can chat on the 'why'. Banning X just on principal seems a bit weak and doing a tooltip as a View seems :/
[01:39] <hatch> yeah get some sleep :)
[01:48] <rick_h__> :) zzzzz
[02:39] <hatch> huwshimi http://codepen.io/ziga-miklic/blog/pure-css-tic-tac-toe/
[02:46] <huwshimi> nice
[06:55] <urulama> rogpeppe1: morning. fyi: i'm driving the kids to their grandma, they had some stomach issues during the night ... be back in 1h max.
[06:55] <rogpeppe1> urulama: ok, thanks
[06:55] <rogpeppe1> urulama: morning too, BTW
[08:34] <frankban> rogpeppe1: morning, I reviewed your branch
[08:34] <rogpeppe1> frankban: ta!
[08:41] <rogpeppe1> frankban: oh twats, it looks like i mixed up two branches
[08:41] <frankban> rogpeppe1: yeah I had that impression
[09:02] <rogpeppe1> frankban: this one should be better: https://github.com/juju/charmstore/pull/73
[09:06] <frankban> rogpeppe1: done
[09:07] <rogpeppe1> urulama: do you want to have a look before I merge?
[09:08] <urulama> rogpeppe1: that's the one from yesterday evening?
[09:08] <rogpeppe1> urulama: yup
[09:08] <rogpeppe1> urulama: although it's got a different PR number now
[09:09] <urulama> rogpeppe1: it was fine yesterday :)
[09:10] <rogpeppe1> urulama: ok, cool. you didn't comment on it yesterday, so i thought you hadn't looked through it.
[09:10] <rogpeppe1> urulama: (actually, it wasn't fine yesterday, as frankban cannily pointed out - i'd mixed in another branch)
[09:16] <urulama> rogpeppe1: i didn't review it, just skip through it as a first glance
[09:16] <rogpeppe1> urulama: np
[09:19] <rogpeppe1> urulama, frankban: i'd appreciate a review of https://github.com/juju/charmstore/pull/72 please
[09:19] <rogpeppe1> (it's pretty trivial)
[09:20] <frankban> rogpeppe1: so also charms and utils are updated to newer versions on that branch, correct?
[09:21] <rogpeppe1> frankban: yes, because they have also been updated to use gopkg.in/yaml.v1
[09:21] <frankban> rogpeppe1: cool, LGTM
[09:21] <rogpeppe1> frankban: thanks
[09:21] <urulama> rogpeppe1: done
[09:21] <rogpeppe1> urulama: ta!
[09:21] <urulama> rogpeppe1: who changed charms.v3 to yaml?
[09:22] <rogpeppe1> urulama: kat
[09:22] <rogpeppe1> urulama: ha, which reminds me, we should remove that UNSTABLE DEVELOPMENT VERSION notice
[09:22] <urulama> rogpeppe1: should we? :)
[09:23] <rogpeppe1> urulama: https://github.com/juju/charm/pull/39
[09:23] <rogpeppe1> urulama: yes, we must
[09:23] <rogpeppe1> urulama: because it's now used by juju-core
[09:26] <rogpeppe1> urulama, frankban: https://github.com/juju/charm/pull/40
[09:33] <urulama> rogpeppe1: so if a need to verify bundle on read arises (this is not the case now, we rely on a client, iirc), would that be v4 then?
[09:34] <rogpeppe1> urulama: i don't think i understand the question
[09:35] <urulama> rogpeppe1: would such change (adding bundle verification on read) bump the charm version to charm.v4? i guess not, as the api does not change, just asking
[09:36] <rogpeppe1> urulama: yeah, i don't think that would need a version change
[09:53] <rogpeppe> urulama: so are you ok with the PR https://github.com/juju/charm/pull/40 ?
[09:53] <urulama> rogpeppe: i guess we don't have a choice on that, do we :)
[09:53] <rogpeppe> urulama: i don't think so
[09:54] <urulama> rogpeppe: but i also do not see any breaking changes in the near future at this moment 
[09:54] <rogpeppe> urulama: neither me
[09:54] <rogpeppe> urulama: and even if there were, we would need to make a new version
[09:55] <urulama> rogpeppe: that you also don't see it makes me a little more at ease saying it's "stable"
[09:55] <rogpeppe> urulama: good. (i think - i'm having difficulty parsing that sentence :-])
[09:56] <urulama> rogpeppe: ah, yes, thoughts in slavic directly transformed to english, sorry :)
[09:57] <rogpeppe> urulama: :-)
[10:07] <frankban> urulama: FWIW your sentence works in Italian too ;-)
[10:08] <urulama> frankban: :)
[10:11] <rogpeppe> i'm still trying to work out what "that you also don't see" means :-)
[10:16] <urulama> rogpeppe: something like this: the fact, that you also don't see breaking changes to the charm.v3 in the near future, ... 
[10:16] <urulama> :)
[10:16] <rogpeppe> urulama: ah, got it, thanks
[11:02] <urulama> rogpeppe: do we have a doc with possible keys for id/stats/counter/ ?
[11:02] <rogpeppe> urulama: it's mentioned in the charm API doc AFAIR
[11:03] <urulama> rogpeppe: indeed, down in the text. tnx
[11:03] <rogpeppe> urulama: we can easily add to that BTW
[11:04] <urulama> rogpeppe, frankban: good news, i'm QA-ing the charmstore charm with a related mongodb charm ... and seems like i can put stuff in and retrieve the info
[11:04] <rogpeppe> urulama: cool
[11:10] <urulama> rogpeppe: wasn't id/expand-id API already implemented? was it lost? (it's probably just me with false recollections of expandId activity)
[11:10] <rogpeppe> urulama: no, i don't think so
[11:10] <urulama> rogpeppe: tnx
[11:10]  * urulama adds a card
[11:21] <urulama> rogpeppe: seems like stats are not working
[11:22] <rogpeppe> urulama: we currently don't update any stats
[11:22] <rogpeppe> urulama: the machinery is in place, but we don't actually use it yet
[11:22] <urulama> rogpeppe: understood.
[11:23] <urulama> rogpeppe: btw, now that stats was moved to v4 api, do we still need _old directory or can it be removed?
[11:24] <rogpeppe> urulama: i think we should probably remove it
[11:24] <rogpeppe> urulama: it was when i started removing it that i added stats
[11:24] <rogpeppe> urulama: but never got around to removing it...
[11:27] <urulama> rogpeppe: np, it's not important, just aesthetics ...
[11:27] <urulama> rogpeppe: and i'm glad we can get rid of old code :)
[11:28] <rogpeppe> urulama: well, there's still some code in there that we might want
[11:28] <rogpeppe> urulama: but it's easy enough to find it agin
[11:28] <rogpeppe> again
[11:30] <rick_h__> morning party people
[11:33] <urulama> morning there, rick_h__
[11:33] <urulama> rick_h__: hope the weather up there is better then here on the south
[11:34] <rick_h__> urulama: the weather here in Michigan is pretty nice
[11:34] <rick_h__> though we had flooding earlier in the week that shut down a section of the highway I take home
[11:34] <urulama> rick_h__: oooh, home already. 
[11:34] <rick_h__> so after the flight had to detour for a long while :/
[11:34] <rick_h__> yea, today is recovery day 
[11:34] <urulama> rick_h__: hehe, enjoy
[11:35] <rick_h__> but I will be in/out (loading pictures wheee) if anyone needs anything
[11:39] <urulama> rick_h__: some good news, QA[pchamrstore charm accepts 
[11:39] <urulama> ah
[11:48] <urulama> rogpeppe: did we miss the /meta/any int he api?
[11:48] <urulama> rogpeppe: or did just i miss the handler call for it?
[11:48] <rogpeppe> urulama: i think it's implemented, isn't it?
[11:48] <rogpeppe> urulama: it's implemented by the router
[13:05] <jrwren> bac: It turns out that juju get formatting bug was a duplicate which I couldn't find: https://bugs.launchpad.net/juju-core/+bug/1292116
[13:05] <mup> Bug #1292116: juju get output is ugly (broken line wrapping and escape characters) <canonical-is> <config> <papercut> <juju-core:Triaged> <https://launchpad.net/bugs/1292116>
[14:33] <kadams54> guihelp: how do I make a stub (created via makeStubMethod) return a certain value?
[14:34] <hatch> pass it in 
[14:34] <frankban> kadams54: IIRC you just pass the value as the third argument
[14:34] <hatch> var stub = utils.makeStubFunction('returnVal')
[14:34] <hatch> or
[14:34] <hatch> var stub = utils.makeStubMethod(obj, method, returnVal)
[14:35]  * frankban bbiab
[14:35] <hatch> the return val param is actually n...
[14:35] <hatch> so if you specify 3 additional arguments then each time it's called it'll pass the next one
[14:35] <kadams54> Thanks
[14:36] <hatch> kadams54 I recommend checking out the source for those methods, it's pretty cool how it works
[14:37] <kadams54> hatch: I've looked at them before, I was just feeling lazy this morning :-)
[14:39] <hatch> I wrote a 'continue with "this" when "that" is done' addition to it but never landed it because we found a workaround to the problem
[14:49] <hatch> jujugui call in 10 kanban now
[14:58] <hatch> jujugui call in 2
[15:04] <bac> hatch: mojo stuff is proceeding.  good talk with liam today, confirmed what i suspected: the spec as written will not work locally.  it expects you are operating in an openstack environment -- which is where IS developed it.  will talk to michael nelson when he is available tonight.
[15:08] <hatch> bac thanks
[15:09] <bac> hatch: couldn't get hangouts to recognize my headset or headphones... grrr
[15:09] <hatch> blarg
[15:09] <hatch> i've had that happen before
[15:09] <hatch> usually a browser restart is all that's necessary
[15:14] <Makyo> jujugui sorry I missed the call, lost track of time walking the dogs.
[15:19] <kadams54> hatch: So… buildHierarchy now filters out unplaced units, but that causes a problem on down the road. Once the service is deployed (but not the unit), its ID changes, which breaks the relationship between the two.
[15:20] <kadams54> That causes an error to be thrown later, once the unit is placed.
[15:20] <hatch> right, you'll have to use `prepare` handler
[15:21] <kadams54> hatch: Potential solution would be to setup an event handler in the service model on ID changes that also updates related IDs in the units collection.
[15:21] <hatch> see lazyAddMachines 
[15:21] <hatch> kadams54 before it had the 'onParentResults' handler called which would update the appropriate fields
[15:22] <hatch> now we need to add the 'prepare' handler in the event that that handler isn't called
[15:23] <hatch> kadams54 the prepare handler is called before the command is run to make any changes to the record
[15:24] <kadams54> hatch: yeah, I see that, just trying to figure out where this would fit in…
[15:24] <hatch> what do you mean? 
[15:25] <hatch> oh there might be an issue here....
[15:25] <kadams54> If I understand correctly, you want a prepare handler on the deploy service commands, which would update the unit model to the new service ID?
[15:25] <hatch> no on the add unit commands
[15:25] <hatch> which actually won't work 
[15:25] <hatch> becuase I don't think we will know that the ghost service id matches the service id
[15:25] <kadams54> Yeah
[15:26] <kadams54> We need it before then
[15:26] <kadams54> When doing operations with the undeployed unit
[15:26] <kadams54> For example: looking up the service icon for an unplaced unit
[15:28] <hatch> can you gist the data that is in the service db for the deployed service and the add unit command? 
[15:28] <hatch> there may be something we can key off of
[15:29] <hatch> if not I'll have to take another look into the execution order of this after I finish these reviews
[15:39] <kadams54> hatch: https://gist.github.com/kadams54/74a0c7c0a7e2c0b18b8b
[15:40] <kadams54> hatch: looks like we could match on unplacedUnit.charmUrl == service.charm
[15:40] <hatch> yeah that won't work though - you can deploy the same charm twice under two different services
[15:40] <hatch> crud
[15:40] <kadams54> But that would mean changing a lot of places (like icon logic) that currently use unplacedUnit.service
[15:46] <hatch> kadams54 ok looking
[15:48] <hatch> hmmmmmmmmm
[15:55] <hatch> kadams54 can I see what you have so far?
[15:56] <kadams54> Sure
[15:56] <kadams54> https://github.com/juju/juju-gui/pull/496
[15:56] <rogpeppe> jrwren: what series is the charmstore charm designed to run on?
[15:57] <jrwren> rogpeppe: trusy only. rick_h__ said it was OK to not support precise.
[15:58] <hatch> thx looking
[16:10] <hatch> kadams54 this was not designed for this....
[16:10] <hatch> lol
[16:14] <kadams54> :-)
[16:15] <kadams54> What would be the harm in having an event handler update the unit's service field when a service ID changes?
[16:15] <kadams54> hatch: ^
[16:16] <hatch> scalability 
[16:16] <hatch> and we actually destroy/re-create the models
[16:16] <hatch> so that won't work :)
[16:17] <hatch> so kadams54  what needs to be done is the _updateChangesetFromResults call needs to be done changeset wide
[16:19] <kadams54> Not just at specific levels?
[16:19] <hatch> well think about this on the big picture
[16:20] <hatch> no wait
[16:20] <hatch> WAIIIIT
[16:20] <hatch> it's coming to me
[16:20] <hatch> oh yeah this is good
[16:20] <hatch> :)
[16:20] <hatch> actually this was an idea already on the place
[16:20] <hatch> plate
[16:20] <kadams54> hatch: I have a bad feeling about this…
[16:20] <kadams54> ;-)
[16:21] <hatch> lol
[16:21] <hatch> the units need access to the service model itself
[16:21] <hatch> not just the id
[16:21] <hatch> problem is that we destroy the model
[16:21] <hatch> and create a new one with a new id
[16:21] <hatch> this is actually the problem with one of our other bugs/cards
[16:24] <hatch> kadams54 that's going to be quite the undertaking
[16:24] <hatch> so I have an idea which you may be able to investigate
[16:24] <hatch> you generate a list of unplaced units and their id's
[16:24] <jcsackett> huh...CI lint caught an error that local lint did not...
[16:24] <hatch> oh wait that's not gona work.....
[16:25]  * hatch grabs the white erase marker and starts over
[16:25] <kadams54> lol
[16:25] <hatch> jcsackett don't like ;) 
[16:25] <jcsackett> hatch: i was so excited--i remembered to run it this time, and still no love. :p
[16:26] <hatch> lol!
[16:27] <jcsackett> jujugui: can i get two reviews on https://github.com/juju/juju-gui/pull/497 ?
[16:27] <jcsackett> Makyo: do you need a second on your PR, or are you still addressing hatch's notes?
[16:28] <kadams54> jcsackett: I'll take a look.
[16:28] <Makyo> jcsackett, still addressing notes, though feel free to take a look
[16:29] <hatch> kadams54 none of my ideas work thanks to Makyo 
[16:29] <hatch> blame him
[16:29] <hatch> :P
[16:37] <jcsackett> Makyo: cool, i'll look now.
[16:43] <hatch> kadams54 quick call?
[16:43] <kadams54> hatch: sure, standup?
[16:43] <hatch> yup
[16:52] <kadams54> And now I think I'm going to go for a run.
[16:52] <kadams54> ;-)
[16:53] <hatch> :D
[16:53] <hatch> thanks for the chat
[16:53] <hatch> I should start running
[16:53] <hatch> kadams54 do you use any apps or anything
[16:54] <kadams54> Nike for run tracking/logging and couch-to-5K for interval training.
[16:54] <kadams54> Or couch-to-10K, depending on whether I have a 10K race coming up.
[16:56] <hatch> jeebz
[16:56] <hatch> I doubt I could do 1k
[16:56] <hatch> :D
[16:57] <hatch> I wonder if there is a couch-to-fridge app
[16:57] <hatch> :D
[17:02] <hatch> jcsackett your branch.....does it work?
[17:02] <hatch> :)
[17:02] <rick_h__> lol
[17:02] <hatch> love the simplicity 
[17:02] <rick_h__> good question
[17:02] <hatch> wb rick_h__ 
[17:02] <rick_h__> sleep is good
[17:02] <hatch> haha it is!
[17:03] <hatch> I'm spinning up an instance for qa atm
[17:18] <hatch> has anyone ever seen this failure when trying to change the juju-gui-source? 
[17:18] <hatch> 2014-08-14 17:13:44 INFO juju-log fatal: git fetch-pack: expected shallow list
[17:19] <jcsackett> hatch: it does.
[17:20] <jcsackett> hatch: i don't like it, but it works.
[17:23] <hatch> jcsackett I can't qa it....for some reason I can't change the repo....
[17:23] <hatch> it doesn't like your branch or something...
[17:24] <rick_h__> hatch: precise or trusty?
[17:24] <hatch> precise
[17:24] <rick_h__> hatch: the git checkout source stuff only works on trusty due to git changes from precise to trusty
[17:24] <hatch> ohhh
[17:24] <hatch> well NOW you tell me :)
[17:24] <rick_h__> been that way since the trusty charm :P
[17:24] <hatch> for reals? 
[17:24] <rick_h__> yep
[17:24] <hatch> interesting
[17:25] <rick_h__> the git stuff broke and I had to fix it for trusty, but then it broke precise since we were trying to do lightweight checkouts for speed/etc
[17:26] <hatch> ahh gotcha
[17:38]  * rogpeppe is done for the day
[17:38] <rogpeppe> g'night all
[17:39] <hatch> night rogpeppe 
[18:31] <jcsackett> hatch, rick_h__: you can get around it on trusty by using a sha instead of a branch name.
[18:31] <jcsackett> er, on precise.
[18:32] <hatch> ahh
[18:32] <rick_h__> jcsackett: ah cool
[18:40] <jcsackett> rick_h__: you're not actually here, right?
[18:40] <jcsackett> rick_h__: as in, we're not supposed to be doing a call?
[18:41] <rick_h__> jcsackett: right, I'm doing bills atm and watching pics upload :)
[18:41] <rick_h__> recovering
[18:41] <jcsackett> cool.
[18:42] <rick_h__> jcsackett: unless you want to chat then I can do that too :)
[18:46] <hatch> I definitely want to see these pics rick_h__  :) be sure to share 
[18:46] <jcsackett> rick_h__: naw, i'm good. just making sure i wasn't leaving you hanging. :)
[19:01] <hatch> kadams54 hey things going well with that update?
[19:01] <kadams54> hatch: trying to figure out why this method was setup like this…
[19:01] <hatch> well originally we only ever had to do things top-down
[19:01] <kadams54> Why only walk the hierarchy? Why not just walk through the entire changeset?
[19:02] <kadams54> Trying to make sure I understand what the ramifications of changing that approach will be
[19:02] <hatch> the hierarchy WAS a formatted changeset up until today
[19:02] <hatch> :)
[19:16] <hatch> lunching
[19:24] <kadams54> hatch: let me know when you're back. I think I fully understand what needs to happen here :-)
[19:25] <hatch> kadams54 still here, wassup
[19:25] <hatch> call? 
[19:27] <kadams54> hatch: one moment. Working up a gist.
[19:28] <kadams54> hatch: go get lunch :-)
[19:28] <kadams54> hatch: I figured I'd have at least a few minutes to get a psuedo spec worked up :-)
[19:29] <hatch> haha ok
[19:29] <hatch> bbl
[19:32] <kadams54> hatch: ping me once you've refueled and we'll hop on a call. Gist is here: https://gist.github.com/kadams54/d04ca02e2ccf4005a03a
[19:57] <hatch> kadams54 gist looks good
[19:57] <kadams54> Great
[19:57] <kadams54> Working on the tests right now
[20:36] <kadams54> hatch: FYI, pushed the new updateChangesetFromResults out to the PR. Going to add an onParentResult to unit records now.
[22:26] <huwshimi> Morning
[22:37] <hatch> morning huwshimi 
[22:44] <hatch> huwshimi https://github.com/juju/juju-gui/pull/486/files#diff-f05fb78d550f50174f5355a05130fa02R183 I'm now working on making this test work with the new inspector rendering but the uncommitted element is empty
[22:44] <hatch> any idea what I need to add to the unit list to make an uncommitted unit?
[22:45] <huwshimi> hmmm...
[22:45] <hatch> tbh I'm not sure how it worked before haha
[22:46] <hatch> probably because it just glazed over it
[22:46] <huwshimi> hatch: The unit you've added there should be uncommitted. It has no agent_state
[22:46] <hatch> ok I'll step through
[22:48] <huwshimi> hatch: https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/service-overview.js#L895
[22:48] <hatch> hmm I only have the three with agent_states
[22:48] <hatch> odd
[22:49] <hatch> huwshimi doh I fixed it
[22:49] <huwshimi> hatch: Oh, what was it?
[22:50] <hatch> I was adding the unit after it was rendered
[22:50] <hatch> so the databinding probably didn't kick in before it did it's assertion
[22:51] <huwshimi> OH
[22:51] <hatch> I have 1/3 of the inspector overview tests passing
[22:51] <hatch> this conversion is gona be h e double hockeysticks
[22:52] <huwshimi> :)