[01:22] huwshimi: howdy [01:24] jrwren: bac please make sure to use the approp channel for conversations around projects [01:26] rick_h__: Hello! [01:26] huwshimi: how goes? [01:26] rick_h__: Good thanks. Trip went well? [01:27] yea, little hiccup on the way home, but all ends well [01:27] now just very very tired [01:27] in the TZ I started the day it's now 3:30am :) [01:27] haha, oh dear [01:28] anyway, back in town. Will probably stick my nose where it doesn't belong tomorrow. [01:28] but will not be on the AU call/etc [01:28] 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] rick_h__: No problems. Everything is good at the moment. Plenty to do. [01:29] huwshimi: cool, did you get a chance to poke at the 'more menu' at all? [01:29] I didn't see anything that looked like it, wanted to check if we've broken ground on that? [01:29] rick_h__: I haven't got that yet. I can tackle that next. [01:29] huwshimi: ok cool [01:29] rick_h__: Happy for it to be a widget, correct? [01:30] huwshimi: yea, I think so [01:30] huwshimi: we'll leave it for hatch to find a hole in the logic :P [01:30] rick_h__: hehe, no problems. [01:30] blarg [01:31] hehe [01:37] I'd vote to remove everything widget :) [01:38] 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] yeah get some sleep :) [01:48] :) zzzzz [02:39] huwshimi http://codepen.io/ziga-miklic/blog/pure-css-tic-tac-toe/ [02:46] nice [06:55] 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] urulama: ok, thanks [06:55] urulama: morning too, BTW [08:34] rogpeppe1: morning, I reviewed your branch [08:34] frankban: ta! [08:41] frankban: oh twats, it looks like i mixed up two branches [08:41] rogpeppe1: yeah I had that impression [09:02] frankban: this one should be better: https://github.com/juju/charmstore/pull/73 [09:06] rogpeppe1: done [09:07] urulama: do you want to have a look before I merge? [09:08] rogpeppe1: that's the one from yesterday evening? [09:08] urulama: yup [09:08] urulama: although it's got a different PR number now [09:09] rogpeppe1: it was fine yesterday :) [09:10] urulama: ok, cool. you didn't comment on it yesterday, so i thought you hadn't looked through it. [09:10] urulama: (actually, it wasn't fine yesterday, as frankban cannily pointed out - i'd mixed in another branch) [09:16] rogpeppe1: i didn't review it, just skip through it as a first glance [09:16] urulama: np [09:19] urulama, frankban: i'd appreciate a review of https://github.com/juju/charmstore/pull/72 please [09:19] (it's pretty trivial) [09:20] rogpeppe1: so also charms and utils are updated to newer versions on that branch, correct? [09:21] frankban: yes, because they have also been updated to use gopkg.in/yaml.v1 [09:21] rogpeppe1: cool, LGTM [09:21] frankban: thanks [09:21] rogpeppe1: done [09:21] urulama: ta! [09:21] rogpeppe1: who changed charms.v3 to yaml? [09:22] urulama: kat [09:22] urulama: ha, which reminds me, we should remove that UNSTABLE DEVELOPMENT VERSION notice [09:22] rogpeppe1: should we? :) [09:23] urulama: https://github.com/juju/charm/pull/39 [09:23] urulama: yes, we must [09:23] urulama: because it's now used by juju-core [09:26] urulama, frankban: https://github.com/juju/charm/pull/40 [09:33] 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] urulama: i don't think i understand the question [09:35] 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] urulama: yeah, i don't think that would need a version change === rogpeppe1 is now known as rogpeppe [09:53] urulama: so are you ok with the PR https://github.com/juju/charm/pull/40 ? [09:53] rogpeppe: i guess we don't have a choice on that, do we :) [09:53] urulama: i don't think so [09:54] rogpeppe: but i also do not see any breaking changes in the near future at this moment [09:54] urulama: neither me [09:54] urulama: and even if there were, we would need to make a new version [09:55] rogpeppe: that you also don't see it makes me a little more at ease saying it's "stable" === alexpilotti_ is now known as alexpilotti [09:55] urulama: good. (i think - i'm having difficulty parsing that sentence :-]) [09:56] rogpeppe: ah, yes, thoughts in slavic directly transformed to english, sorry :) [09:57] urulama: :-) [10:07] urulama: FWIW your sentence works in Italian too ;-) [10:08] frankban: :) [10:11] i'm still trying to work out what "that you also don't see" means :-) [10:16] rogpeppe: something like this: the fact, that you also don't see breaking changes to the charm.v3 in the near future, ... [10:16] :) [10:16] urulama: ah, got it, thanks [11:02] rogpeppe: do we have a doc with possible keys for id/stats/counter/ ? [11:02] urulama: it's mentioned in the charm API doc AFAIR [11:03] rogpeppe: indeed, down in the text. tnx [11:03] urulama: we can easily add to that BTW [11:04] 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] urulama: cool [11:10] 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] urulama: no, i don't think so [11:10] rogpeppe: tnx [11:10] * urulama adds a card [11:21] rogpeppe: seems like stats are not working [11:22] urulama: we currently don't update any stats [11:22] urulama: the machinery is in place, but we don't actually use it yet [11:22] rogpeppe: understood. [11:23] rogpeppe: btw, now that stats was moved to v4 api, do we still need _old directory or can it be removed? [11:24] urulama: i think we should probably remove it [11:24] urulama: it was when i started removing it that i added stats [11:24] urulama: but never got around to removing it... [11:27] rogpeppe: np, it's not important, just aesthetics ... [11:27] rogpeppe: and i'm glad we can get rid of old code :) [11:28] urulama: well, there's still some code in there that we might want [11:28] urulama: but it's easy enough to find it agin [11:28] again [11:30] morning party people [11:33] morning there, rick_h__ [11:33] rick_h__: hope the weather up there is better then here on the south [11:34] urulama: the weather here in Michigan is pretty nice [11:34] though we had flooding earlier in the week that shut down a section of the highway I take home [11:34] rick_h__: oooh, home already. [11:34] so after the flight had to detour for a long while :/ [11:34] yea, today is recovery day [11:34] rick_h__: hehe, enjoy [11:35] but I will be in/out (loading pictures wheee) if anyone needs anything [11:39] rick_h__: some good news, QA[pchamrstore charm accepts [11:39] ah [11:48] rogpeppe: did we miss the /meta/any int he api? [11:48] rogpeppe: or did just i miss the handler call for it? [11:48] urulama: i think it's implemented, isn't it? [11:48] urulama: it's implemented by the router [13:05] 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] Bug #1292116: juju get output is ugly (broken line wrapping and escape characters)

[14:33] guihelp: how do I make a stub (created via makeStubMethod) return a certain value? [14:34] pass it in [14:34] kadams54: IIRC you just pass the value as the third argument [14:34] var stub = utils.makeStubFunction('returnVal') [14:34] or [14:34] var stub = utils.makeStubMethod(obj, method, returnVal) [14:35] * frankban bbiab [14:35] the return val param is actually n... [14:35] so if you specify 3 additional arguments then each time it's called it'll pass the next one [14:35] Thanks [14:36] kadams54 I recommend checking out the source for those methods, it's pretty cool how it works [14:37] hatch: I've looked at them before, I was just feeling lazy this morning :-) [14:39] 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] jujugui call in 10 kanban now [14:58] jujugui call in 2 [15:04] 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] bac thanks [15:09] hatch: couldn't get hangouts to recognize my headset or headphones... grrr [15:09] blarg [15:09] i've had that happen before [15:09] usually a browser restart is all that's necessary [15:14] jujugui sorry I missed the call, lost track of time walking the dogs. [15:19] 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] That causes an error to be thrown later, once the unit is placed. [15:20] right, you'll have to use `prepare` handler [15:21] 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] see lazyAddMachines [15:21] kadams54 before it had the 'onParentResults' handler called which would update the appropriate fields [15:22] now we need to add the 'prepare' handler in the event that that handler isn't called [15:23] kadams54 the prepare handler is called before the command is run to make any changes to the record [15:24] hatch: yeah, I see that, just trying to figure out where this would fit in… [15:24] what do you mean? [15:25] oh there might be an issue here.... [15:25] 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] no on the add unit commands [15:25] which actually won't work [15:25] becuase I don't think we will know that the ghost service id matches the service id [15:25] Yeah [15:26] We need it before then [15:26] When doing operations with the undeployed unit [15:26] For example: looking up the service icon for an unplaced unit [15:28] can you gist the data that is in the service db for the deployed service and the add unit command? [15:28] there may be something we can key off of [15:29] if not I'll have to take another look into the execution order of this after I finish these reviews [15:39] hatch: https://gist.github.com/kadams54/74a0c7c0a7e2c0b18b8b [15:40] hatch: looks like we could match on unplacedUnit.charmUrl == service.charm [15:40] yeah that won't work though - you can deploy the same charm twice under two different services [15:40] crud [15:40] But that would mean changing a lot of places (like icon logic) that currently use unplacedUnit.service [15:46] kadams54 ok looking [15:48] hmmmmmmmmm [15:55] kadams54 can I see what you have so far? [15:56] Sure [15:56] https://github.com/juju/juju-gui/pull/496 [15:56] jrwren: what series is the charmstore charm designed to run on? [15:57] rogpeppe: trusy only. rick_h__ said it was OK to not support precise. [15:58] thx looking [16:10] kadams54 this was not designed for this.... [16:10] lol [16:14] :-) [16:15] What would be the harm in having an event handler update the unit's service field when a service ID changes? [16:15] hatch: ^ [16:16] scalability [16:16] and we actually destroy/re-create the models [16:16] so that won't work :) [16:17] so kadams54 what needs to be done is the _updateChangesetFromResults call needs to be done changeset wide [16:19] Not just at specific levels? [16:19] well think about this on the big picture [16:20] no wait [16:20] WAIIIIT [16:20] it's coming to me [16:20] oh yeah this is good [16:20] :) [16:20] actually this was an idea already on the place [16:20] plate [16:20] hatch: I have a bad feeling about this… [16:20] ;-) [16:21] lol [16:21] the units need access to the service model itself [16:21] not just the id [16:21] problem is that we destroy the model [16:21] and create a new one with a new id [16:21] this is actually the problem with one of our other bugs/cards [16:24] kadams54 that's going to be quite the undertaking [16:24] so I have an idea which you may be able to investigate [16:24] you generate a list of unplaced units and their id's [16:24] huh...CI lint caught an error that local lint did not... [16:24] oh wait that's not gona work..... [16:25] * hatch grabs the white erase marker and starts over [16:25] lol [16:25] jcsackett don't like ;) [16:25] hatch: i was so excited--i remembered to run it this time, and still no love. :p [16:26] lol! [16:27] jujugui: can i get two reviews on https://github.com/juju/juju-gui/pull/497 ? [16:27] Makyo: do you need a second on your PR, or are you still addressing hatch's notes? [16:28] jcsackett: I'll take a look. [16:28] jcsackett, still addressing notes, though feel free to take a look [16:29] kadams54 none of my ideas work thanks to Makyo [16:29] blame him [16:29] :P [16:37] Makyo: cool, i'll look now. [16:43] kadams54 quick call? [16:43] hatch: sure, standup? [16:43] yup [16:52] And now I think I'm going to go for a run. [16:52] ;-) [16:53] :D [16:53] thanks for the chat [16:53] I should start running [16:53] kadams54 do you use any apps or anything [16:54] Nike for run tracking/logging and couch-to-5K for interval training. [16:54] Or couch-to-10K, depending on whether I have a 10K race coming up. [16:56] jeebz [16:56] I doubt I could do 1k [16:56] :D [16:57] I wonder if there is a couch-to-fridge app [16:57] :D [17:02] jcsackett your branch.....does it work? [17:02] :) [17:02] lol [17:02] love the simplicity [17:02] good question [17:02] wb rick_h__ [17:02] sleep is good [17:02] haha it is! [17:03] I'm spinning up an instance for qa atm [17:18] has anyone ever seen this failure when trying to change the juju-gui-source? [17:18] 2014-08-14 17:13:44 INFO juju-log fatal: git fetch-pack: expected shallow list [17:19] hatch: it does. [17:20] hatch: i don't like it, but it works. [17:23] jcsackett I can't qa it....for some reason I can't change the repo.... [17:23] it doesn't like your branch or something... [17:24] hatch: precise or trusty? [17:24] precise [17:24] hatch: the git checkout source stuff only works on trusty due to git changes from precise to trusty [17:24] ohhh [17:24] well NOW you tell me :) [17:24] been that way since the trusty charm :P [17:24] for reals? [17:24] yep [17:24] interesting [17:25] 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] ahh gotcha [17:38] * rogpeppe is done for the day [17:38] g'night all [17:39] night rogpeppe === lazyPower_ is now known as lazyPower [18:31] hatch, rick_h__: you can get around it on trusty by using a sha instead of a branch name. [18:31] er, on precise. [18:32] ahh [18:32] jcsackett: ah cool [18:40] rick_h__: you're not actually here, right? [18:40] rick_h__: as in, we're not supposed to be doing a call? [18:41] jcsackett: right, I'm doing bills atm and watching pics upload :) [18:41] recovering [18:41] cool. [18:42] jcsackett: unless you want to chat then I can do that too :) [18:46] I definitely want to see these pics rick_h__ :) be sure to share [18:46] rick_h__: naw, i'm good. just making sure i wasn't leaving you hanging. :) [19:01] kadams54 hey things going well with that update? [19:01] hatch: trying to figure out why this method was setup like this… [19:01] well originally we only ever had to do things top-down [19:01] Why only walk the hierarchy? Why not just walk through the entire changeset? [19:02] Trying to make sure I understand what the ramifications of changing that approach will be [19:02] the hierarchy WAS a formatted changeset up until today [19:02] :) [19:16] lunching [19:24] hatch: let me know when you're back. I think I fully understand what needs to happen here :-) [19:25] kadams54 still here, wassup [19:25] call? [19:27] hatch: one moment. Working up a gist. [19:28] hatch: go get lunch :-) [19:28] hatch: I figured I'd have at least a few minutes to get a psuedo spec worked up :-) [19:29] haha ok [19:29] bbl [19:32] 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] kadams54 gist looks good [19:57] Great [19:57] Working on the tests right now [20:36] hatch: FYI, pushed the new updateChangesetFromResults out to the PR. Going to add an onParentResult to unit records now. [22:26] Morning [22:37] morning huwshimi [22:44] 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] any idea what I need to add to the unit list to make an uncommitted unit? [22:45] hmmm... [22:45] tbh I'm not sure how it worked before haha [22:46] probably because it just glazed over it [22:46] hatch: The unit you've added there should be uncommitted. It has no agent_state [22:46] ok I'll step through [22:48] hatch: https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/service-overview.js#L895 [22:48] hmm I only have the three with agent_states [22:48] odd [22:49] huwshimi doh I fixed it [22:49] hatch: Oh, what was it? [22:50] I was adding the unit after it was rendered [22:50] so the databinding probably didn't kick in before it did it's assertion [22:51] OH [22:51] I have 1/3 of the inspector overview tests passing [22:51] this conversion is gona be h e double hockeysticks [22:52] :)