| rick_h__ | huwshimi: howdy | 01:22 |
|---|---|---|
| rick_h__ | jrwren: bac please make sure to use the approp channel for conversations around projects | 01:24 |
| huwshimi | rick_h__: Hello! | 01:26 |
| rick_h__ | huwshimi: how goes? | 01:26 |
| huwshimi | rick_h__: Good thanks. Trip went well? | 01:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| huwshimi | hehe | 01:31 |
| hatch | I'd vote to remove everything widget :) | 01:37 |
| 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:38 |
| hatch | yeah get some sleep :) | 01:39 |
| rick_h__ | :) zzzzz | 01:48 |
| hatch | huwshimi http://codepen.io/ziga-miklic/blog/pure-css-tic-tac-toe/ | 02:39 |
| huwshimi | nice | 02:46 |
| 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 | 06:55 |
| frankban | rogpeppe1: morning, I reviewed your branch | 08:34 |
| rogpeppe1 | frankban: ta! | 08:34 |
| rogpeppe1 | frankban: oh twats, it looks like i mixed up two branches | 08:41 |
| frankban | rogpeppe1: yeah I had that impression | 08:41 |
| rogpeppe1 | frankban: this one should be better: https://github.com/juju/charmstore/pull/73 | 09:02 |
| frankban | rogpeppe1: done | 09:06 |
| rogpeppe1 | urulama: do you want to have a look before I merge? | 09:07 |
| 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:08 |
| urulama | rogpeppe1: it was fine yesterday :) | 09:09 |
| 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:10 |
| urulama | rogpeppe1: i didn't review it, just skip through it as a first glance | 09:16 |
| rogpeppe1 | urulama: np | 09:16 |
| 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:19 |
| frankban | rogpeppe1: so also charms and utils are updated to newer versions on that branch, correct? | 09:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| rogpeppe1 | urulama, frankban: https://github.com/juju/charm/pull/40 | 09:26 |
| 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:33 |
| rogpeppe1 | urulama: i don't think i understand the question | 09:34 |
| 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:35 |
| rogpeppe1 | urulama: yeah, i don't think that would need a version change | 09:36 |
| === rogpeppe1 is now known as rogpeppe | ||
| 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:53 |
| 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:54 |
| urulama | rogpeppe: that you also don't see it makes me a little more at ease saying it's "stable" | 09:55 |
| === alexpilotti_ is now known as alexpilotti | ||
| rogpeppe | urulama: good. (i think - i'm having difficulty parsing that sentence :-]) | 09:55 |
| urulama | rogpeppe: ah, yes, thoughts in slavic directly transformed to english, sorry :) | 09:56 |
| rogpeppe | urulama: :-) | 09:57 |
| frankban | urulama: FWIW your sentence works in Italian too ;-) | 10:07 |
| urulama | frankban: :) | 10:08 |
| rogpeppe | i'm still trying to work out what "that you also don't see" means :-) | 10:11 |
| 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 | 10:16 |
| 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:02 |
| urulama | rogpeppe: indeed, down in the text. tnx | 11:03 |
| rogpeppe | urulama: we can easily add to that BTW | 11:03 |
| 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:04 |
| 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:10 | |
| urulama | rogpeppe: seems like stats are not working | 11:21 |
| 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:22 |
| urulama | rogpeppe: btw, now that stats was moved to v4 api, do we still need _old directory or can it be removed? | 11:23 |
| 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:24 |
| 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:27 |
| 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:28 |
| rick_h__ | morning party people | 11:30 |
| urulama | morning there, rick_h__ | 11:33 |
| urulama | rick_h__: hope the weather up there is better then here on the south | 11:33 |
| 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:34 |
| rick_h__ | but I will be in/out (loading pictures wheee) if anyone needs anything | 11:35 |
| urulama | rick_h__: some good news, QA[pchamrstore charm accepts | 11:39 |
| urulama | ah | 11:39 |
| 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 | 11:48 |
| 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> | 13:05 |
| kadams54 | guihelp: how do I make a stub (created via makeStubMethod) return a certain value? | 14:33 |
| 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:34 |
| * 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:35 |
| hatch | kadams54 I recommend checking out the source for those methods, it's pretty cool how it works | 14:36 |
| kadams54 | hatch: I've looked at them before, I was just feeling lazy this morning :-) | 14:37 |
| 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:39 |
| hatch | jujugui call in 10 kanban now | 14:49 |
| hatch | jujugui call in 2 | 14:58 |
| 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:04 |
| hatch | bac thanks | 15:08 |
| 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:09 |
| Makyo | jujugui sorry I missed the call, lost track of time walking the dogs. | 15:14 |
| 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:19 |
| 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:20 |
| 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:21 |
| hatch | now we need to add the 'prepare' handler in the event that that handler isn't called | 15:22 |
| hatch | kadams54 the prepare handler is called before the command is run to make any changes to the record | 15:23 |
| kadams54 | hatch: yeah, I see that, just trying to figure out where this would fit in… | 15:24 |
| hatch | what do you mean? | 15:24 |
| 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:25 |
| 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:26 |
| 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:28 |
| hatch | if not I'll have to take another look into the execution order of this after I finish these reviews | 15:29 |
| kadams54 | hatch: https://gist.github.com/kadams54/74a0c7c0a7e2c0b18b8b | 15:39 |
| 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:40 |
| hatch | kadams54 ok looking | 15:46 |
| hatch | hmmmmmmmmm | 15:48 |
| hatch | kadams54 can I see what you have so far? | 15:55 |
| 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:56 |
| jrwren | rogpeppe: trusy only. rick_h__ said it was OK to not support precise. | 15:57 |
| hatch | thx looking | 15:58 |
| hatch | kadams54 this was not designed for this.... | 16:10 |
| hatch | lol | 16:10 |
| kadams54 | :-) | 16:14 |
| 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:15 |
| hatch | scalability | 16:16 |
| hatch | and we actually destroy/re-create the models | 16:16 |
| hatch | so that won't work :) | 16:16 |
| hatch | so kadams54 what needs to be done is the _updateChangesetFromResults call needs to be done changeset wide | 16:17 |
| kadams54 | Not just at specific levels? | 16:19 |
| hatch | well think about this on the big picture | 16:19 |
| 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:20 |
| 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:21 |
| 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:24 |
| * 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:25 |
| hatch | lol! | 16:26 |
| 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:27 |
| kadams54 | jcsackett: I'll take a look. | 16:28 |
| Makyo | jcsackett, still addressing notes, though feel free to take a look | 16:28 |
| hatch | kadams54 none of my ideas work thanks to Makyo | 16:29 |
| hatch | blame him | 16:29 |
| hatch | :P | 16:29 |
| jcsackett | Makyo: cool, i'll look now. | 16:37 |
| hatch | kadams54 quick call? | 16:43 |
| kadams54 | hatch: sure, standup? | 16:43 |
| hatch | yup | 16:43 |
| kadams54 | And now I think I'm going to go for a run. | 16:52 |
| kadams54 | ;-) | 16:52 |
| 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:53 |
| 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:54 |
| hatch | jeebz | 16:56 |
| hatch | I doubt I could do 1k | 16:56 |
| hatch | :D | 16:56 |
| hatch | I wonder if there is a couch-to-fridge app | 16:57 |
| hatch | :D | 16:57 |
| 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:02 |
| hatch | I'm spinning up an instance for qa atm | 17:03 |
| 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:18 |
| jcsackett | hatch: it does. | 17:19 |
| jcsackett | hatch: i don't like it, but it works. | 17:20 |
| 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:23 |
| 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:24 |
| 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:25 |
| hatch | ahh gotcha | 17:26 |
| * rogpeppe is done for the day | 17:38 | |
| rogpeppe | g'night all | 17:38 |
| hatch | night rogpeppe | 17:39 |
| === lazyPower_ is now known as lazyPower | ||
| 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:31 |
| hatch | ahh | 18:32 |
| rick_h__ | jcsackett: ah cool | 18:32 |
| 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:40 |
| rick_h__ | jcsackett: right, I'm doing bills atm and watching pics upload :) | 18:41 |
| rick_h__ | recovering | 18:41 |
| jcsackett | cool. | 18:41 |
| rick_h__ | jcsackett: unless you want to chat then I can do that too :) | 18:42 |
| 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. :) | 18:46 |
| 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:01 |
| 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:02 |
| hatch | lunching | 19:16 |
| kadams54 | hatch: let me know when you're back. I think I fully understand what needs to happen here :-) | 19:24 |
| hatch | kadams54 still here, wassup | 19:25 |
| hatch | call? | 19:25 |
| kadams54 | hatch: one moment. Working up a gist. | 19:27 |
| 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:28 |
| hatch | haha ok | 19:29 |
| hatch | bbl | 19:29 |
| 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:32 |
| hatch | kadams54 gist looks good | 19:57 |
| kadams54 | Great | 19:57 |
| kadams54 | Working on the tests right now | 19:57 |
| kadams54 | hatch: FYI, pushed the new updateChangesetFromResults out to the PR. Going to add an onParentResult to unit records now. | 20:36 |
| huwshimi | Morning | 22:26 |
| hatch | morning huwshimi | 22:37 |
| 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:44 |
| huwshimi | hmmm... | 22:45 |
| hatch | tbh I'm not sure how it worked before haha | 22:45 |
| 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:46 |
| 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:48 |
| hatch | huwshimi doh I fixed it | 22:49 |
| huwshimi | hatch: Oh, what was it? | 22:49 |
| 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:50 |
| 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:51 |
| huwshimi | :) | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!