| menn0 | wallyworld__: ping? | 00:10 |
|---|---|---|
| sinzui | Oh fab, CI thinks trunk is bzr because the first 8 chars of the hash are numbers | 00:43 |
| wallyworld | lol | 00:48 |
| wallyworld | :-( | 00:48 |
| menn0 | wallyworld: do you have time for a quick chat about gridfs? | 00:50 |
| mwhudson | hahaha | 01:01 |
| wwitzel3 | someone have time to hangout, I need an ear to bend about the approach of this refactoring fwereade has suggested to me. | 01:03 |
| wallyworld__ | thumper-afk: meeting? when you get back? | 02:05 |
| wallyworld__ | axw: you had any breakthroughs on the session closed errors etc? | 02:06 |
| axw | wallyworld__: nope | 02:07 |
| wallyworld__ | it will probably be something simple once the cause is found | 02:08 |
| wallyworld__ | axw: so you checking that precise cloud init supports the new apt feature? | 02:09 |
| axw | wallyworld__: I have checked it works with cloud-init, I'm just checking the sshinit bit works on precise too | 02:09 |
| axw | no reason for it not to, but I should be thorough | 02:09 |
| wallyworld__ | great, thank you | 02:10 |
| wallyworld__ | just checking you aren't stuck for stuff to do | 02:10 |
| wallyworld__ | the address change stuff still wip i assume | 02:10 |
| axw | wallyworld__: well, not actually working on that atm. I want to get some more agreement first. I did finish the unit config-change bit | 02:11 |
| wallyworld__ | np, do you need me to poke william? | 02:11 |
| axw | wallyworld__: need some more discussion with hazmat I think | 02:12 |
| wallyworld__ | ok. the next largish chunk of work is to replace http storage. but i'd like to see if we can get the tests sorted first | 02:13 |
| axw | okey dokey | 02:13 |
| wallyworld__ | worth spending some time on the tests as it will have a big affect on team velocity plus we will learn lessons that can be shared and used | 02:14 |
| axw | wallyworld__: I think you said perrito666 was working on separating StateInfo from storage? | 02:14 |
| axw | I think that will be a prereq to get it to work | 02:15 |
| axw | sure | 02:15 |
| wallyworld__ | yeah, there's supposed to be a new api or some such - that's what william told me | 02:15 |
| wallyworld__ | so we can do the http stuff and also replace cloud storage | 02:15 |
| wallyworld__ | for tools, charms | 02:15 |
| wallyworld__ | but i also have to move the storage stuff to a separate repo | 02:16 |
| wallyworld__ | but i want martin to get the lander sorted out first | 02:16 |
| wallyworld__ | i'll check the StateInfo progress also | 02:16 |
| katco | wallyworld__: unit tests pass; doing empirical testing now, and should have a pull request contingent on that | 02:18 |
| perrito666 | wallyworld__: axwI am not working on such feature | 02:18 |
| wallyworld__ | katco: great :-D | 02:18 |
| perrito666 | wallyworld__: axw not that I can remember | 02:18 |
| axw | perrito666: ah ok. maybe someone else | 02:19 |
| wallyworld__ | perrito666: william indicated there would be an api to allow state server addresses to be found without having to reply on a file stored in environment storage | 02:19 |
| axw | katco: hello! you're working rather late aren't you? | 02:19 |
| wallyworld__ | maybe it wasn't you? i thought i was but i could be wrong | 02:19 |
| katco | axw: i am :p but i'm interested. i want to get this change in so i have a clean plate tomorrow. i won't make a habit of it ;) | 02:20 |
| katco | i also got distracted by my stupid addiction to food. | 02:21 |
| waigani | axw: do you have an example of an error path releasing resources? I know you and davecheney have been working on it recently. What's the correct and incorrect way now? | 02:21 |
| perrito666 | wallyworld__: mm, I am about to sleep now but if you could email me that It would be greatly appreciated we might be only having misscomunication due to the fact that should be sleeping | 02:21 |
| wallyworld__ | ok :-) | 02:21 |
| wallyworld__ | good night | 02:21 |
| perrito666 | wallyworld__: tx | 02:21 |
| davecheney | today in "Dave waits for the build bot": listening to podcasts and filing bugs :( | 02:21 |
| axw | waigani: I just meant make sure files and such are closed when a function exits | 02:22 |
| waigani | ah right | 02:22 |
| axw | "defer f.Close()" usually | 02:22 |
| waigani | sure | 02:22 |
| davecheney | github.com/juju/juju/juju/testing/conn.go | 02:22 |
| davecheney | my god, who thought that was a good idea | 02:22 |
| * katco pulls up a seat next to davecheney. ah, bootstrapping juju machine agent. a fascinating show. | 02:22 | |
| wallyworld__ | katco: well, you'll have 2 clean plates - one the food was on the the other your todo list :-) | 02:23 |
| * davecheney ages visibly waiting for juju bootstrap | 02:23 | |
| axw | davecheney: you should disable apt-get upgrade... oh wait.. :) | 02:23 |
| * davecheney grins, morbidly | 02:24 | |
| waigani | it's like a magic spell - you have write say 'juju' at least three times for it to work ;) | 02:24 |
| axw | wallyworld__: bootstrapping precise works with eatmydata | 02:24 |
| davecheney | hmm, https://bugs.launchpad.net/juju-core/+bug/1337038 | 02:24 |
| _mup_ | Bug #1337038: cmd/juju: map ordering test failure <juju-core:New> <https://launchpad.net/bugs/1337038> | 02:24 |
| wallyworld__ | axw: \o/ | 02:24 |
| davecheney | i wonder how this happened | 02:24 |
| axw | wallyworld__: or rather, it works despite eatmydata not being installed | 02:25 |
| axw | by default | 02:25 |
| davecheney | http://img3.wikia.nocookie.net/__cb20140108021302/villains/images/2/27/Beetlejuice.jpg | 02:25 |
| katco | wallyworld__: i suppose i should assign this bug to myself on launchpad? | 02:25 |
| wallyworld__ | katco: yes, sorry i should have mentioned that | 02:26 |
| axw | I'm tempted to write a program to transform the tests so that it randomise everything that isn't guaranteed to be deterministic | 02:26 |
| katco | wallyworld__: no worries... i just wasn't sure what the workflow was | 02:26 |
| wallyworld__ | katco: and before we moved to github, it would be marked as fix commited automatically after the branch merged but now we need to do it manually | 02:26 |
| wallyworld__ | axw: or upgrade Go to use the new map implementation :-) | 02:27 |
| katco | wallyworld__: ew bummer. maybe we can do a jenkins or github trigger to update it. i assume launchpad has an api? | 02:27 |
| wallyworld__ | katco: yeah, it's on the "do this to make things nicer once the core stuff works" list | 02:27 |
| katco | wallyworld__: should i flag this fix for a milestone? or is that someone elses purview? | 02:27 |
| katco | wallyworld__: gotcha. i think i have a slide in my presentation that says something along the lines of, "your iteration is the only thing that will happen again and again. making it better has multiplicative returns" | 02:28 |
| wallyworld__ | katco: normally the bug would be assigned a milestone, usually "next-stable-release", and then moved to the correct actual milestone one the release number milestone gtes created | 02:28 |
| katco | wallyworld__: ok, i'll do that | 02:29 |
| wallyworld__ | katco: someone would normally do that, but i got distracted as I just picked out some simple bugs for you that were not on the radar so to speak | 02:30 |
| katco | wallyworld__: oh ok. np. thanks for the bugs :) | 02:30 |
| wallyworld__ | anytime, i have *lots* more :-) | 02:30 |
| katco | gee, sorry. i only fix 1 bug per team. (cough) | 02:30 |
| katco | ;) | 02:31 |
| axw | wallyworld__: I think we should remove the second "go test" from the lander now | 02:34 |
| axw | it's just holding up the queue now | 02:34 |
| wallyworld__ | axw: i'm inclined to agree, but i think we can (and do) still get spurious failures on full parallelisation? | 02:34 |
| axw | wallyworld__: I've seen it once since I made my change | 02:35 |
| axw | wallyworld__: I think that's low enough rate to get people to resubmit | 02:35 |
| wallyworld__ | true, and if there's a real failure, it will report quicker | 02:36 |
| axw | right | 02:36 |
| wallyworld__ | makes it harder to now if we've fixed the race too :-) | 02:37 |
| wallyworld__ | know | 02:37 |
| axw | heh. I'll see if I can reproduce the bugs in a VM with slower I/O | 02:37 |
| wallyworld__ | axw: martin should be calling the bog standard script from the release tools repo - but i think he still needs to switch over. i'll get him to turn off retry when he does that today/tonight | 02:38 |
| axw | cool | 02:38 |
| wallyworld__ | katco: the logging stuff - loggo comes with a default stderr writer registered. the various agents are configured to run via upstart, and have their stdout/err directed to a log file - see juju/upstart/service.go | 02:40 |
| wallyworld__ | so that's how the log calls get stuff to a log file | 02:40 |
| katco | aha! | 02:41 |
| katco | wallyworld__: thank you! | 02:41 |
| wallyworld__ | katco: so, next step is to figure out how to tell upstart how to create the file with different permissions | 02:41 |
| sinzui | wallyworld__, If I read this run correctly, only 2 tests fail in lxc with -p 2 | 02:41 |
| wallyworld__ | that i do not know off hand | 02:41 |
| wallyworld__ | sinzui: which run? | 02:42 |
| sinzui | wallyworld__, looks like 1.20 at f325c87bd1dc92ac58bdc347568a6d901b607172 | 02:43 |
| wallyworld__ | sinzui: with andrew's change to use tmpfs, tests are now very reliable. so more may fail in lxc due to slower i/o as it seems slow i/o has a repeatable negative impact on the tests | 02:43 |
| wallyworld__ | sinzui: you mean that the above revision looks like it is good for release as 1.20? | 02:45 |
| waigani | davecheney, menn0: thanks for your input :) | 02:45 |
| sinzui | wallyworld__, that log claims to be the 1.20 we were testing all day | 02:46 |
| menn0 | waigani: no problems. that list might well help me. | 02:46 |
| waigani | nice! | 02:46 |
| sinzui | wallyworld__, I see a new round of tests started with master. I can run the lxc version of the test with this run | 02:46 |
| wallyworld__ | sinzui: can you point me at the log toy refer to? | 02:46 |
| wallyworld__ | ok | 02:47 |
| katco | wallyworld__: ok, i think i've submitted a pull request. what would i paste here to get a review? | 02:47 |
| wwitzel3 | so I have a package in environs that contains a bunch of interfaces and struct all related to exposing parts of the environ to state. Right now I have that package named "hackage" .. obviously that won't work, looking for suggestions. | 02:47 |
| wallyworld__ | katco: you can reasonably expect the on call reviewer to pick it up. but you can also paste the pull request url here and beg offer $$$$ for a review. i only accept $100 bills | 02:47 |
| katco | rofl | 02:48 |
| katco | well here it is: https://github.com/juju/juju/pull/232 | 02:48 |
| * menn0 thinks wallyworld__ hates him ... :) | 02:48 | |
| katco | i expect that i have done something wrong | 02:48 |
| katco | so let me know :p | 02:48 |
| sinzui | wallyworld__, This the log I was reading: http://juju-ci.vapour.ws:8080/job/walk-unit-tests-trusty-amd64/1115/consoleText | 02:48 |
| wallyworld__ | katco: you for getting something..... ? | 02:48 |
| katco | oh right | 02:48 |
| wallyworld__ | menn0: why? | 02:48 |
| * katco hands wallyworld__ a $100 bill and a wet trout | 02:48 | |
| menn0 | I've been ping and PMing you all day | 02:48 |
| menn0 | wallyworld__: ^^ | 02:49 |
| menn0 | wallyworld__: but no response | 02:49 |
| * menn0 puts on big sad puppy dog eyes | 02:49 | |
| wallyworld__ | menn0: sorry, i often miss private pings because i don't hear the notification and your nic is off my screen, and also my connecton for irc has been flakey :-( | 02:49 |
| wallyworld__ | sorry :-( | 02:49 |
| katco | oh wow davecheney is all over that. thanks :) | 02:49 |
| wallyworld__ | menn0: also you didn't give me money like katco just did | 02:50 |
| menn0 | wallyworld__: so that's what it takes these days... | 02:50 |
| katco | psst, menn0, it was monopoly money. he doesn't notice! | 02:50 |
| menn0 | katco: thanks for the tip. I wonder if he takes dogecoin? | 02:51 |
| katco | LOL | 02:51 |
| wwitzel3 | menn0: also, he told me he hates you | 02:51 |
| wwitzel3 | :P | 02:51 |
| menn0 | wwitzel3: I KNEW it! | 02:52 |
| wwitzel3 | menn0: hey wanna help me name something? :) | 02:52 |
| menn0 | wwitzel3: ummm sure | 02:52 |
| * menn0 wonders if this is a trap | 02:52 | |
| wallyworld__ | wwitzel3: i hate you too :-) | 02:52 |
| wwitzel3 | menn0: see about comment .. I have a package currently called hackage in environs that contains interfaces and a struct that is used to represent information needed about an environ to state. | 02:53 |
| wwitzel3 | s/about/above | 02:53 |
| wallyworld__ | sinzui: that's not a bad test run for being inside lxc - only a few things to fix :-) | 02:53 |
| katco | ok so now i've commented with $$merge$$, and jenkins will pick that up and perform a build and then merge if it's clean? | 02:53 |
| wallyworld__ | katco: yep | 02:53 |
| wwitzel3 | wallyworld__: haha, well at least I know you feel something! :P | 02:53 |
| katco | nice! which build am i interested in? | 02:53 |
| wallyworld__ | wwitzel3: there's a line there but this is a family channel | 02:54 |
| wwitzel3 | wallyworld__: hah | 02:54 |
| wallyworld__ | katco: http://juju-ci.vapour.ws:8080/job/github-merge-juju/ | 02:54 |
| * menn0 thinks | 02:54 | |
| wallyworld__ | katco: but the queue is full of other jobs right now | 02:55 |
| katco | wallyworld__: ty. how long does it usually take the worker to pick that up? assuming workers are free | 02:55 |
| wallyworld__ | katco: we are moving the landing job to it's own slave soon | 02:55 |
| katco | cool | 02:55 |
| wallyworld__ | katco: you will see an email within a minute | 02:55 |
| axw | katco: you need to make your juju membership public on github | 02:55 |
| wallyworld__ | if the queue is not blocked | 02:55 |
| axw | otherwise the bot ignores your comment | 02:55 |
| wallyworld__ | oh yeah, that too | 02:55 |
| axw | katco: https://github.com/orgs/juju/members | 02:55 |
| rick_h__ | wallyworld__: whatever happened to cake being the official offering? | 02:56 |
| wallyworld__ | rick_h__: cake can't buy love | 02:56 |
| wallyworld__ | $$$$ can | 02:56 |
| rick_h__ | wallyworld__: thought back in the LP days cake was the offering for things, sad to see that sell out and go all $$ | 02:56 |
| menn0 | wwitzel3: what kind of stuff about environs is being exposed to state? | 02:56 |
| wallyworld__ | rick_h__: indeed. but these here are crazy time. new world order. survival of the fittest | 02:57 |
| rick_h__ | hah | 02:57 |
| katco | axw: ok thanks, i've done that | 02:57 |
| wwitzel3 | menn0: ConfigValidator, PrecheckerInstance, EnvironCapability, and InstananceDistributor .. state combines them all under a Policy interface to represent a given environ. | 02:57 |
| wallyworld__ | katco: your job is now pending | 02:57 |
| menn0 | wwitzel3: environ_policy or environ_state_policy? | 02:59 |
| menn0 | wwitzel3: environ_state? | 02:59 |
| menn0 | wwitzel3: not that great I realise... | 02:59 |
| wwitzel3 | menn0: yeah, was thinking something along those lines, environs already has a statepolicy which does some of the marshalling of the data, so I was thinking of creating an environ_state and moving that under along with the current "hackage" stuff. | 03:00 |
| wwitzel3 | menn0: but then, I hate to use state again anywhere, lol | 03:00 |
| axw | wwitzel3: are there new bits in hackage, or are you just moving existing things? | 03:00 |
| menn0 | wwitzel3: yeah - it sounds reasonable (based on my limited understanding on what you're doing) | 03:01 |
| wwitzel3 | axw: just moving things so that environs no long depends on state | 03:01 |
| axw | ok | 03:01 |
| axw | environs/policy? | 03:01 |
| wwitzel3 | axw: I was running in to some import cycle issues when implementing the EnvironmentAPI and fwereade pointed out this would be good chance to sever that dep which really isn't needed. | 03:01 |
| katco | wallyworld__: so say this fails for some reason, what is the workflow? | 03:01 |
| wallyworld__ | katco: you fix the failure, push, and type $$merge$$ again | 03:02 |
| wwitzel3 | axw: hrmm, yeah that actually makes sense since it is the environ policy and the whole point is that is doesn't care about state. | 03:02 |
| wallyworld__ | katco: if it's a suprious failure in the bot, just type $$merge$$ | 03:02 |
| wwitzel3 | axw: I guess I thinking about it too much | 03:02 |
| axw | wwitzel3: yup. it's just a way for things to hook into environment behaviour | 03:02 |
| rick_h__ | wallyworld__: dont' you all have to remove the 'merge request accepted' comment in github? | 03:02 |
| katco | wallyworld__: so i should be very interested in the results of this job, as it's on me to fix the merge? is the merge gated? will it still merge if the build fails? | 03:03 |
| wallyworld__ | rick_h__: we don't / haven't been | 03:03 |
| rick_h__ | wallyworld__: and the extra $$merge$$ should do nothing. :/ | 03:03 |
| wwitzel3 | menn0, axw: thanks, I will go with environs/policy and people can suggest alternatives during review if they so desire :) | 03:03 |
| wallyworld__ | katco: merge is gated, yes | 03:03 |
| katco | great | 03:03 |
| rick_h__ | ummm, ok. That's interesting | 03:03 |
| wallyworld__ | katco: won't merge untl the tests pass | 03:03 |
| wallyworld__ | rick_h__: why? | 03:03 |
| menn0 | wwitzel3: sounds ok to me | 03:03 |
| katco | i was interested that the tests take so long. is it b/c it's tied into mongo? | 03:04 |
| rick_h__ | wallyworld__: because that's the way I wrote it to work. Extra $$merge$$ aren't supposed to do anything | 03:04 |
| rick_h__ | wow, you guys are crazy, 35 running pull requests | 03:04 |
| axw | wwitzel3: SGTM. I *think* you just want to move the interfaces in there, and leave the statepolicy.go (impl) stuff where it is | 03:04 |
| axw | wwitzel3: does that sound right? | 03:04 |
| wallyworld__ | rick_h__: seems to work for us :-) | 03:04 |
| rick_h__ | wallyworld__: yea interesting. Trying to figure out why. lol | 03:04 |
| axw | wwitzel3: just so the state and environs packages have a common interface to reference | 03:05 |
| axw | without depending on one another | 03:05 |
| rick_h__ | wallyworld__: heh so it works by accident fyi. The idea was that the bot checks if there's 'merge request accepted' comment and if so, it doesn't rerun the merge job. https://github.com/juju/juju/pull/224 | 03:06 |
| wwitzel3 | axw: yeah, I realized that looking at it, you're right. | 03:06 |
| rick_h__ | wallyworld__: so the way to rerun is supposed to be to remove that 'merge request accepted' comment. | 03:06 |
| wallyworld__ | rick_h__: lol ok | 03:06 |
| rick_h__ | wallyworld__: glad it's working for you, I'll have to make sure not to fix that 'bug' :) | 03:06 |
| wallyworld__ | rick_h__: it's now a feature :-) | 03:07 |
| rick_h__ | hah, extra added feature | 03:07 |
| katco | curious why my job doesn't have any text on it | 03:08 |
| davecheney | https://github.com/juju/juju/pull/233 | 03:09 |
| davecheney | axw: thanks for the review | 03:16 |
| davecheney | the rabbit hole just keeps going | 03:16 |
| axw | davecheney: nps | 03:16 |
| katco | yay i landed my first change :) | 03:16 |
| katco | thank you for the help everyone! | 03:17 |
| davecheney | katco: and you didn't break the build | 03:17 |
| davecheney | nor did you delete the whole CI infrastructure | 03:17 |
| davecheney | (long story) | 03:17 |
| katco | there's still time! i can make another change! | 03:17 |
| davecheney | so, thumbs up! | 03:17 |
| katco | give me a chance! | 03:17 |
| rick_h__ | davecheney: lol | 03:18 |
| sinzui | We can put CI back in a couple hours, all that ci machines can be deploy with juju | 03:19 |
| sinzui | This is the 3rd ci because canonistack lost the first 2 | 03:20 |
| rick_h__ | sinzui: yea, we have some sublte steps. The lander, system deps, etc are manual still | 03:21 |
| rick_h__ | sinzui: though we're going to work on automating it more. | 03:21 |
| rick_h__ | sinzui: but we had a new team member wipe out CI on his frist day on accident | 03:21 |
| rick_h__ | sinzui: so it's the nice story going around | 03:22 |
| sinzui | rick_h__, :) | 03:22 |
| === thumper-afk is now known as thumper | ||
| thumper | wallyworld: sorry, have been having a sick day and away | 03:23 |
| thumper | thought I might have come back after lunch | 03:23 |
| thumper | but still not feeling so shit hot | 03:23 |
| thumper | so I'm going to sign off | 03:24 |
| thumper | and see how I am tomorrow | 03:24 |
| thumper | wallyworld: perhaps we can chat tomorrow? | 03:24 |
| sinzui | rick_h__, there are 14 machines in ci 3's env, but the machine count is 53. I have lost 40 machines in the last 3 months | 03:24 |
| rick_h__ | sinzui: ouch | 03:24 |
| rick_h__ | sinzui: we're up to 4 in one env now, but only because of the ec2/co-locating limitation now | 03:24 |
| wallyworld | thumper: sure np. i'm off tomorrow. the main thing was the resources stuff. but you can reply to the email and we have a tentative meeting next week with rick_h__ and friends | 03:25 |
| rick_h__ | bwuhahaha, how can I ruin more of thumper's days? | 03:25 |
| wallyworld | katco: sorry, was on another call | 03:26 |
| wallyworld | katco: you can click the console output link to see the job text | 03:26 |
| katco | wallyworld: np. it landed | 03:26 |
| sinzui | davecheney, Maybe you want to look into this issue soon, or at least advise someone about how to fix it https://bugs.launchpad.net/juju-core/+bug/1337063 | 03:26 |
| katco | yeah i had stood up jenkins at my last shop :) | 03:26 |
| wallyworld | katco: \o/ yay, you are now *officially* a juju-core team member :-P | 03:26 |
| katco | woohoo! | 03:26 |
| rick_h__ | lol congrats katco | 03:27 |
| katco | now to grok more so i can contribute more difficult changes | 03:27 |
| wallyworld | rick_h__: or should that be commisserations :-) | 03:27 |
| katco | haha | 03:27 |
| rick_h__ | wallyworld: not sure what kind of crappy medal you all hand out to the new folks :P | 03:27 |
| katco | nah we will do great things together. | 03:27 |
| wallyworld | ah, the newbies are always so optimistic :-) | 03:27 |
| rick_h__ | katco: what TZ are you? | 03:27 |
| katco | alexisb told me i get $100 for each commit? is that right? | 03:28 |
| katco | rick_h__: GMT-6 | 03:28 |
| davecheney | sinzui: we have two options | 03:28 |
| davecheney | 1. roll back that change | 03:28 |
| wallyworld | katco: yep, here you go .... $100 | 03:28 |
| rick_h__ | katco: oh get out of here | 03:28 |
| katco | woo! | 03:28 |
| davecheney | 2. fork the ssh/terminal package | 03:28 |
| rick_h__ | katco: don't be like wallyworld and I working at night. | 03:28 |
| sinzui | yuck for 2 | 03:28 |
| wallyworld | rick_h__: it's not my night yet :-) | 03:28 |
| wwitzel3 | rick_h__: haha, was just going to say, I know what TZ you're in :P | 03:28 |
| katco | lol, i just wanted to get that 1st change in while wallyworld was on | 03:28 |
| rick_h__ | wallyworld: yea, but I'll see you in my morning your night and we know it :P | 03:28 |
| wallyworld | lol | 03:29 |
| rick_h__ | wwitzel3: some of us don't know any better any more, but katco has time yet to get on the right path | 03:29 |
| wallyworld | last night i had a night off :-) drinking with friends :-) | 03:29 |
| rick_h__ | wallyworld: woot! I'm going into the woods for the holiday. No cell coverage | 03:29 |
| rick_h__ | wallyworld: only a 'clubhouse' with 500kbs wifi connection to the world | 03:29 |
| wallyworld | rick_h__: enjoy that. fireworks in the forrest not so good tough | 03:29 |
| rick_h__ | wallyworld: there's a lake they set them off over | 03:30 |
| wallyworld | rick_h__: 500kbps. party likes it's 2001 :-) | 03:30 |
| rick_h__ | hoping to get some nice pics with my new camera gear | 03:30 |
| wwitzel3 | rick_h__: nice, I'm going to shoot toxic powdered metal in to the sky after lighting it on fire. | 03:30 |
| * wallyworld loves photography | 03:30 | |
| rick_h__ | wwitzel3: woot! | 03:30 |
| wallyworld | rick_h__: what gear you got? | 03:30 |
| rick_h__ | wallyworld: yea, my new hobby, having fun | 03:30 |
| rick_h__ | wallyworld: pany gx7 micro 4/3 with a suite of lenses, mefoto tripid, etc | 03:30 |
| wwitzel3 | he uses iPhone + Instagram | 03:30 |
| wallyworld | lol | 03:31 |
| rick_h__ | https://www.flickr.com/photos/7508761@N03/ | 03:31 |
| rick_h__ | lol | 03:31 |
| rick_h__ | no apple allowed! | 03:31 |
| wallyworld | rick_h__: nice. i got a nikkon D7000 with nice wide angle, a 70-300 tele, and 35mm prime | 03:31 |
| wallyworld | rick_h__: those portraits are nice | 03:32 |
| wwitzel3 | I have Sony aSomething or other with 3 lenes .. and I use my phone for all my pictures :/ | 03:32 |
| wallyworld | wwitzel3: rotrl | 03:32 |
| rick_h__ | wallyworld: yea, learning and practicing | 03:32 |
| rick_h__ | wwitzel3: heh, that's why I went with micro 4/3. It's smaller and closer to something I can carry around | 03:33 |
| wallyworld | rick_h__: just no naked selfies, PLEASE | 03:33 |
| rick_h__ | though with my 100-300 lens (200-600 effective) it's a bit big | 03:33 |
| wwitzel3 | rick_h__: yeah, I like that form factor, will probably sell my full size and try it out. | 03:33 |
| rick_h__ | https://www.flickr.com/photos/7508761@N03/14497325923/ the boy with a 45mm oly prime I got. I just focused on the wrong eye for this pic :/ | 03:33 |
| wwitzel3 | rick_h__, wallyworld: the only thing I really use it for is doing portraits, I have a fixed focal length lense. | 03:34 |
| wwitzel3 | "How do you zoom out?" .. "With your feet" | 03:34 |
| rick_h__ | https://www.flickr.com/photos/7508761@N03/14423103076/ | 03:34 |
| wallyworld | wwitzel3: yep, i here you. i use my 35mm prime as my main lens | 03:34 |
| wallyworld | hear | 03:34 |
| rick_h__ | heh, ok I need to close up shop and go to bed at some point, have fun all. | 03:35 |
| wallyworld | rick_h__: see ya | 03:35 |
| wwitzel3 | rick_h__: ttyl | 03:35 |
| rick_h__ | wallyworld: thanks for the notes/docs, and so forth. Will look forward to causing each other work soon :) | 03:35 |
| wallyworld | rick_h__: yeah, right back at ya | 03:35 |
| wallyworld | rick_h__: i really want to porgess this stuff :-) | 03:35 |
| wallyworld | progress | 03:35 |
| wallyworld | axw: if we want to see lots of spurious failures, look at the output of the job to run tests inside lxc that sinzui set up eg http://juju-ci.vapour.ws:8080/job/walk-unit-tests-trusty-amd64/1116/console | 03:48 |
| wallyworld | and 1115 before that etc | 03:48 |
| sinzui | wallyworld, yeah | 03:48 |
| sinzui | I was just pondering a --safe-retry switch to just run tests with -p2, and do it twice | 03:49 |
| wallyworld | if we make makes that job happy, our test suite will indeed rock | 03:49 |
| axw | wallyworld: ok | 03:49 |
| axw | looking... | 03:49 |
| axw | yuck :( | 03:49 |
| wallyworld | sinzui: not a bad idea. we are considering turning off retry option for landing tests now that they seem a lot more reliable running with tmpfs | 03:50 |
| wallyworld | axw: yeah, shows how far we've got to go | 03:50 |
| wallyworld | because we do have ambitions of running the tests isolated in lxc | 03:50 |
| sinzui | wallyworld, I don't know what your considering. I try tests 4 times with all procs. I was thinking of trying 2 times with only 2 procs. It might be faster on average | 03:51 |
| === vladk|offline is now known as vladk | ||
| wallyworld | sinzui: for the landing tests to gate commits to trunk, we have been running once and then again with -p 2 if the first run failed. now the tests are more reliable, we are looking to turn off the retry option and just fail the run | 03:52 |
| sinzui | wallyworld, My samples of those tests shows that -p 2 was making them pass most of the time, just run with -p 2 | 03:53 |
| wwitzel3 | wallyworld, axw: https://github.com/juju/juju/pull/234 .. I'm off for the night, but any feedback would be great. | 03:53 |
| sinzui | well, I will set that up in some parallel testing to get so better data | 03:53 |
| wwitzel3 | wallyworld: the Environment API implmentation is "done", but I'll want to get #234 in first, since I've re-worked it branched off that. | 03:54 |
| wallyworld | sinzui: that's a fair bit slower, and since axw switched to tmpfs, we have had maybe 1 spurious falure out of several runs | 03:54 |
| axw | wwitzel3: no worries, will take a look a bit later. | 03:54 |
| sinzui | That would be nice wallyworld | 03:54 |
| wallyworld | wwitzel3: looking, thank you | 03:54 |
| wwitzel3 | wallyworld: so once I get #234 merged, I'll get the EnvironCapability API stuff up for review. | 03:54 |
| wallyworld | great :-) | 03:54 |
| wallyworld | sinzui: the tmpfs change shows how fragile our tests are and that we have work to do | 03:55 |
| wallyworld | but for now, it has helped the landing tests be more reliable | 03:55 |
| davecheney | wallyworld: axw nice one | 04:07 |
| davecheney | the bot is landing changes in 10 minutes | 04:07 |
| davecheney | well, it runs the tests in 10 minutes | 04:07 |
| davecheney | setup is still a few minutes | 04:07 |
| davecheney | but it is significantly better than a few days ago | 04:07 |
| wallyworld | davecheney: set up will disappear "soon" also | 04:07 |
| wallyworld | davecheney: and using tmpfs marks our poor tests/race conditions, but gives us scope to fix without holding people up | 04:08 |
| wallyworld | masks | 04:08 |
| davecheney | wallyworld: i always mount /tmp with a ramfr | 04:11 |
| davecheney | wallyworld: i always mount /tmp with a ramfs | 04:11 |
| davecheney | i don't think it's an invalid setup | 04:11 |
| wallyworld | davecheney: slow i/o should not cause tests to fail in a racey way | 04:12 |
| wallyworld | the setup is valid but the tests ares till broken | 04:12 |
| wallyworld | s/broken/suboptimal | 04:12 |
| wallyworld | davecheney: and there's lots of failures running the tests inside an lxc container | 04:12 |
| wallyworld | due to the same/similar root causes | 04:13 |
| wallyworld | axw: nice doc | 04:16 |
| axw | wallyworld: thanks | 04:17 |
| axw | is that addition of supported providers ok? | 04:17 |
| axw | for automatic spread | 04:17 |
| wallyworld | axw: yep, +1. thanks | 04:21 |
| === vladk is now known as vladk|offline | ||
| jcw4 | PTAL https://github.com/juju/juju/pull/216 | 05:26 |
| === urulama-away is now known as urulama | ||
| === vladk|offline is now known as vladk | ||
| rogpeppe | ha, i've just seen this: https://godoc.org/github.com/dropbox/godropbox/errors#Wrap | 06:23 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| wallyworld__ | jam1: so we currently use a mechanism at bootstrap time to save the inst id of the bootstrap machine of cloud storage ie bootstrap.SaveState bootstrap.LoadState etc. Do we still need that with all the api and login etc changes since that was all done? | 07:13 |
| wallyworld__ | s/of cloud storage/in cloud storage | 07:15 |
| wallyworld__ | axw: agree existing tests are shitty. sadly i think if we truly want to fix all the races we'll need to touch a lot more of them | 07:18 |
| wallyworld__ | s/touch/rethink | 07:18 |
| axw | yeah :/ | 07:18 |
| axw | I cna't see a way to do it without major changes | 07:18 |
| wallyworld__ | understood :-( | 07:19 |
| wallyworld__ | might be a chance to blaze th trail | 07:19 |
| TheMue | morning | 07:19 |
| wallyworld__ | Guten Morgen | 07:20 |
| axw | wallyworld__: we *could* get rid of the provider-state file from storage (with some minor updates to bootstrap?), but if the addresses change and the client does not have any valid addresses it has no way to get back in | 07:20 |
| TheMue | wallyworld__: hehe, yes o/ | 07:20 |
| wallyworld__ | axw: agreed. i had heard mention though we were working around that somehow | 07:21 |
| wallyworld__ | that's what i'm not sure about the status of | 07:21 |
| axw | ok | 07:21 |
| wallyworld__ | i'm not sure how though as if we don't know the address, how do we discover the new one | 07:21 |
| wallyworld__ | will be impossible t get rid of cloud storage without figuring this out | 07:22 |
| axw | wallyworld__: for the CLI, there's options, but I don't know about agents | 07:25 |
| axw | wallyworld__: for the CLI we could tag instances and query via the provider interface | 07:25 |
| wallyworld__ | axw: yeah, that did occur to me also. not sure how portable it would be | 07:26 |
| axw | wallyworld__: for agents, we could do something horrible like push the addresses to each of the agents via SSH | 07:26 |
| axw | (from the state server) | 07:26 |
| wallyworld__ | juju run new-addresses :-) | 07:27 |
| axw | yeah that'd work I guess | 07:27 |
| wallyworld__ | i was not really serious :-) | 07:27 |
| wallyworld__ | but it could be something at the correct level of abstraction | 07:28 |
| davecheney | axw: EUREKA! | 07:29 |
| davecheney | i've caught mgo doing something stupic | 07:29 |
| axw | davecheney: ?! | 07:29 |
| davecheney | stupid | 07:29 |
| axw | ooh | 07:29 |
| davecheney | http://paste.ubuntu.com/7740699/ | 07:29 |
| axw | buh | 07:30 |
| davecheney | the mgo pinger, v2/mgo/server.go | 07:30 |
| davecheney | has a loop | 07:30 |
| wallyworld__ | davecheney: don't you mean "something else" | 07:30 |
| mattyw | morning folks | 07:30 |
| davecheney | which is supposed to exit the pinger if there is an error | 07:30 |
| wallyworld__ | oh you mean the driver, not mongo itself | 07:30 |
| davecheney | except it is very selective about the thigns it consisders and error | 07:30 |
| davecheney | thos prints 'pinger discarded' | 07:30 |
| davecheney | are all things the pinger things are _not_ errors | 07:30 |
| davecheney | and so stays alive, probing a dead ass mongo db over and over again | 07:31 |
| axw | interesting | 07:31 |
| axw | so that's why we have so many goroutines lying about? | 07:31 |
| davecheney | yup | 07:31 |
| davecheney | especially in the tests | 07:32 |
| wallyworld__ | davecheney: nice pickup, well done | 07:32 |
| axw | do you think it has anything to do with "session already closed"? | 07:32 |
| davecheney | axw: it is at least related | 07:32 |
| davecheney | although probbably not the direct cause | 07:32 |
| davecheney | ther is other dodgy shit happening, for sure | 07:32 |
| dimitern | mgz, wallyworld__, what instance type are we using for the github lander bot? | 07:32 |
| axw | m3.xlarge | 07:33 |
| dimitern | nice! | 07:33 |
| wallyworld__ | yup | 07:33 |
| davecheney | dimitern: an m3 xlarge is roughly 80% of the speed of my two year old x220 | 07:33 |
| dimitern | I've just seen the console log with the tests - it takes 80s to run the joyent tests - it takes like 650s on my machine | 07:33 |
| davecheney | this cloud thing isn't good value | 07:33 |
| wallyworld__ | davecheney: you going to email gustavo? | 07:34 |
| davecheney | wallyworld__: when I have something concrete | 07:34 |
| wallyworld__ | ok | 07:34 |
| axw | davecheney: it *should* break out of the loop when the mongoServer is closed | 07:36 |
| davecheney | axw: yup | 07:36 |
| davecheney | and it probably did a long time ago | 07:36 |
| davecheney | but i suspect there are paths that can return an error aside from errServerClosed [sic] | 07:37 |
| davecheney | especially when we mix in timeouts, tls and your own custom dialer functions | 07:37 |
| axw | davecheney: ah right, it doesn't check that flag in the other error condition | 07:37 |
| axw | doh | 07:37 |
| davecheney | axw: insert sad trombone | 07:39 |
| davecheney | axw: its on my list of things to glare at | 07:40 |
| === vladk is now known as vladk|offline | ||
| axw | goodo | 07:40 |
| * axw glares at other flaky tests | 07:40 | |
| davecheney | axw: at the moment I am composing a manifesto entitled "teardownTest considered harmful" | 07:41 |
| davecheney | i want to replace all our teardown logic with cleanupSuite style logic | 07:41 |
| davecheney | ie, somehign like | 07:41 |
| davecheney | st, err := state.Open(...) | 07:41 |
| davecheney | c.Assert(err, gc.IsNil) | 07:41 |
| davecheney | s.State = st | 07:41 |
| davecheney | s.DeferTest(func( ...)) | 07:42 |
| davecheney | or even | 07:42 |
| davecheney | s.DeferTest(s.State.Close()) | 07:42 |
| dimitern | jam1, hey, i was thinking - now that the apiserver listens by default on ipv4 and ipv6, do we need the test suite at all? | 07:42 |
| axw | davecheney: SGTM, but we need to be careful about mixing the two. I've had to fix things where a cleanup happened after a teardown but should have come before | 07:42 |
| davecheney | axw: yup | 07:42 |
| davecheney | ordering will continue to be an issue | 07:42 |
| davecheney | at the moment, as a generalisation all the teardown stuite / test stuff is written expecting the setup to succeed | 07:43 |
| davecheney | which makes sense | 07:43 |
| davecheney | what does a TearDownTest do ? | 07:43 |
| davecheney | it tries it's hardest to undo everything setup test did | 07:43 |
| davecheney | but there is a communication issue here | 07:43 |
| davecheney | for every action that setup test / suite does | 07:43 |
| davecheney | we need to signal somehow to teardown that the action succeeded, not exploded | 07:44 |
| davecheney | so I think a pattern that looks like a test or suite scoped defer makes more sense than the current way teardown works | 07:44 |
| dimitern | hey davecheney - any progress on adding the on call reviewer to the calendar? | 07:44 |
| davecheney | dimitern: none whatsoever | 07:44 |
| davecheney | i've looked at the spreadsheet a few times | 07:44 |
| davecheney | but the care factor is very low | 07:45 |
| davecheney | hmm | 07:45 |
| davecheney | it's thurstday today | 07:45 |
| dimitern | right :) | 07:45 |
| davecheney | which means' i'm going to have to own up to not doing it ... | 07:45 |
| === vladk|offline is now known as vladk | ||
| davecheney | still, tim too like three months to not do something on his action list | 07:45 |
| davecheney | i think I should be ok | 07:45 |
| davecheney | axw: pinger discarded error: dial tcp 0.1.2.3:1234: invalid argument | 07:46 |
| davecheney | this one is very concerning | 07:46 |
| davecheney | that says that mgo is starting a pinger before the first db connections has been opened | 07:46 |
| davecheney | so it's going to sit there | 07:46 |
| davecheney | trying to dial, and will never get errServerClosed, becuase the server will never be opened ... | 07:47 |
| axw | :/ | 07:47 |
| davecheney | i think i can open a bug on that basis | 07:49 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| davecheney | https://codereview.appspot.com/101670043/ | 08:03 |
| davecheney | these two constants are side a pain the backside | 08:04 |
| voidspace | morning all | 08:15 |
| mattyw | axw, still awake? | 08:45 |
| axw | mattyw: otp | 08:56 |
| mattyw | axw, ok no problem, I'll just keep typing and you can response whenever is good | 08:57 |
| mattyw | axw, just wanted to check I understood your feeback. For -n 1 just returning the error is fine. for -n > 1 we should just return the error (failed to create n machines). And then the second part is make sure all error messages go to stderr | 08:58 |
| voidspace | hmmm... it looks like initiating a replicaset with ipv6 ip address (rather than hostname) fails | 08:58 |
| voidspace | trying with ipv4 ip address | 08:58 |
| axw | mattyw: at the moment the single error case just returns the error. the multi-error case prints *and* returns the error. I think we should be consistent between single and multi | 09:01 |
| axw | mattyw: so actually probably the best thing to do is to create an error that will look nice when printed by the cmd code | 09:01 |
| axw | (for the multi error case) | 09:01 |
| axw | and not print them in there at all | 09:02 |
| axw | mattyw: make sense? | 09:02 |
| axw | atm the multi-error case will print twice: once in the addmachine.go code, and once in the cmd code | 09:02 |
| axw | (because an error was returned) | 09:02 |
| mattyw | axw, I think I understand. In both cases don't print, just contruct a nice error and return it. In the single error case it's fine as it is. In multiple errors contruct an error that joins all the errors that happened | 09:07 |
| axw | mattyw: yup | 09:09 |
| mattyw | axw, got it, thanks for the feedback | 09:09 |
| axw | nps | 09:09 |
| === urulama is now known as urulama-away | ||
| voidspace | jam1: I seem to be bumping into this with ipv6 replicaset configuration | 09:17 |
| voidspace | jam1: https://jira.mongodb.org/browse/SERVER-11664 | 09:17 |
| voidspace | jam1: I get the error in this bug report when I create a replica set with ipv6 addresses | 09:17 |
| voidspace | jam1: "couldn't initiate : can't find self in the replset config my port" | 09:18 |
| voidspace | it says resolved | 09:18 |
| voidspace | the report is against 2.4.8, Trusty has 2.4.9 | 09:18 |
| jam1 | voidspace: that bug says it is a dupe of : https://jira.mongodb.org/browse/SERVER-5436 | 09:18 |
| voidspace | indeed | 09:18 |
| voidspace | which is unresolved | 09:18 |
| voidspace | even if you disambiguate the ipv6 address ([::1]:port) it serializes it in an ambiguous form it seems | 09:19 |
| jam1 | voidspace: the thing is https://jira.mongodb.org/browse/SERVER-5436 says ::1:PORT is bad, but it should be using [::1]:PORT which is not ambiguous | 09:19 |
| voidspace | that's what I'm using | 09:19 |
| voidspace | right | 09:20 |
| jam1 | voidspace: so what are the actual values that you're setting? | 09:21 |
| voidspace | [::1]:port | 09:21 |
| voidspace | where the port comes from the MgoInstance | 09:21 |
| voidspace | fmt.Sprintf("[::1]:%v", inst.Port()) | 09:21 |
| voidspace | and that code works fine for creating and dialling a mongo instance | 09:22 |
| voidspace | it's just the replicaset config that fails | 09:22 |
| jam1 | voidspace: sure, the bug for https://jira.mongodb.org/browse/SERVER-11664 is saying that it can't find its own address in your replicaset config, so we have to figure out what it thinks its own address is. | 09:22 |
| jam1 | voidspace: ugh... https://jira.mongodb.org/browse/SERVER-9612 | 09:23 |
| jam1 | "Backport: No" | 09:23 |
| jam1 | "Fix Versions: 2.7 desired" | 09:24 |
| voidspace | :-/ | 09:24 |
| TheMue | voidspace: jam1: shit | 09:25 |
| jam1 | voidspace: TheMue: this is why we investigate if Mongo *actually* supports ipv6 :) | 09:25 |
| TheMue | jam1: but with the hope to get a better result :D | 09:26 |
| voidspace | maybe this is why they disable it by default | 09:26 |
| jam1 | voidspace: https://jira.mongodb.org/browse/SERVER-5436 also says "Fix Versions: 2.7" | 09:26 |
| jam1 | so not even 2.6 has the fix... ? | 09:26 |
| jam1 | vladk: you've poked around the mongo source code, can you confirm if things might be better in 2.6? | 09:26 |
| voidspace | jam1: 5436 is unresolved anyway | 09:26 |
| voidspace | jam1: so not fixed yet | 09:26 |
| jam1 | voidspace: same for https://jira.mongodb.org/browse/SERVER-9612 | 09:27 |
| jam1 | now, we don't use "mongos" in our setup (I believe) | 09:27 |
| jam1 | TheMue: this is the kind of Port/Address parsing that is broken in IPv6 that I was worried we were doing in *our* code, looks like we aren't but Mongo is. | 09:28 |
| voidspace | jam1: we could use /etc/hosts and hostnames... | 09:28 |
| TheMue | jam1: so we’ve done our homework ;) | 09:29 |
| voidspace | coffee | 09:29 |
| mwhudson | jam1: there is no mongos in juju-mongodb so i hope you don't try to use it :) | 09:30 |
| voidspace | mwhudson: mongo serialises ipv6 addresses in a format it can't then parse... | 09:30 |
| TheMue | jam1: when testing the go funcs I first stumbled with addresses like ::1:12345 too and got an error returned | 09:30 |
| mwhudson | voidspace: yeah, sounds like fun | 09:30 |
| voidspace | mwhudson: yep :-) | 09:30 |
| jam1 | voidspace: well "can't parse correctly" it parses it, just gets the wrong answer :) | 09:31 |
| vladk | voidspace: I have tested replicaset, I didn't use brackets in host string and specified port: host: "fd00::30:27017". It worked. | 09:31 |
| TheMue | vladk: aha? *wonder* | 09:32 |
| voidspace | vladk: I could try getting the address of this machine instead of ::1 | 09:32 |
| voidspace | just trying ::1:port | 09:32 |
| voidspace | not looking good so far (either the test passes quickly or I have to wait for the timeout to see the error) | 09:33 |
| voidspace | so getting coffee | 09:33 |
| vladk | voidspace: see my yesterday doc: https://docs.google.com/a/canonical.com/document/d/1mfLSIUAV5V7_uj3oxBDIGxlT5jPOKIXsWlmyO6pa23Y/edit | 09:34 |
| voidspace | vladk: ok, so your rs.initiate call works | 09:34 |
| voidspace | vladk: that's where in the code it's dying for me | 09:35 |
| voidspace | ok, so with "::1:port" it fails for a very different reason that might be fixable | 09:35 |
| voidspace | &mgo.QueryError{Code:13144, Message:"exception: need most members up to reconfigure, not ok : ::1:40577", Assertion:false} | 09:35 |
| voidspace | jam1: so the specific bug is that it always treats the last :port as :port | 09:36 |
| voidspace | jam1: so long as we're *always* specifying a port (which we are) I think we avoid that bug | 09:36 |
| voidspace | jam1: *and* they don't like the square brackets syntax | 09:36 |
| voidspace | jam1: so we might be ok | 09:36 |
| jam1 | voidspace: so (a) we have to be giving external addresses, because the other hosts have to be able to see this one, right? | 09:36 |
| jam1 | and then we can't use [::]:port because when it looks for self it usesf ::1:port syntax | 09:37 |
| jam1 | and string compare | 09:37 |
| jam1 | voidspace: well https://jira.mongodb.org/browse/SERVER-9612 says 'mongos' will treat everything after the *first* : as a port, but we don't directly use mongos | 09:37 |
| voidspace | jam1: what do you mean by " so (a) we have to be giving external addresses, because the other hosts have to be able to see this one, right?" | 09:37 |
| jam1 | voidspace: "we can't use ::1" (a loopback address), | 09:37 |
| voidspace | jam1: ah right, yeah - but that's not a problem in practise | 09:38 |
| TheMue | voidspace: and in tests? | 09:38 |
| jam1 | (13:36:00) voidspace: &mgo.QueryError{Code:13144, Message:"exception: need most members up to reconfigure, not ok : ::1:40577", Assertion:false} | 09:38 |
| voidspace | TheMue: failing for a different reason now that I haven't worked out yet - but it looks hopeful | 09:38 |
| jam1 | looks like we are trying to reconfigure | 09:38 |
| jam1 | but don't have quorum | 09:38 |
| voidspace | jam1: that is when we remove a member, which is a reconfigure | 09:39 |
| voidspace | jam1: but that same code passes when using "localhost:port", it's the ipv6 version that raises that error | 09:39 |
| jam1 | voidspace: so probably if you were getting that error, we just hadn't reached stability yet | 09:39 |
| TheMue | voidspace: did you pushed your current code to your GH? so that I can also see it? | 09:39 |
| voidspace | TheMue: not yet I can | 09:39 |
| jam1 | voidspace: are you sure it isn't just a timing thing? | 09:39 |
| TheMue | voidspace: thx | 09:39 |
| voidspace | jam1: it's just a copy paste - may well be a timing error | 09:39 |
| voidspace | jam1: this is a new failure reason - furthest I've got! | 09:40 |
| jam1 | voidspace: "most members up" certainly looks timing related. :) | 09:40 |
| voidspace | jam1: and it's this bug that says that mongo will always parse the address with last part as port | 09:40 |
| voidspace | jam1: https://jira.mongodb.org/browse/SERVER-5436 | 09:40 |
| voidspace | jam1: the mongos is a red herring for us I think | 09:40 |
| voidspace | jam1: just "yet another mongo ipv6 parsing bug" | 09:40 |
| voidspace | cool, so it's probably not a dealbreaker which I thought it was | 09:41 |
| jam1 | voidspace: https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/hostandport.cpp looks to just be doing "string.rfind(':')" | 09:42 |
| jam1 | so yeah, as long as we always supply port (which we do) it should be ok | 09:42 |
| voidspace | TheMue: https://github.com/voidspace/juju/tree/replicaset-ipv6 | 09:43 |
| voidspace | TheMue: voidspace/juju/replicaset-ipv6 | 09:43 |
| * voidspace *really* goes for coffee | 09:43 | |
| TheMue | voidspace: thanks, just had to finish a mail. I’m fighting in parallel with the fussiness to get docs online. :D | 09:44 |
| jam1 | voidspace: I'm curious, what is ipv6 specific about: dialAndTestInitiateIPv6 | 09:44 |
| TheMue | jam1: not using the test root instance and passing an address | 09:48 |
| TheMue | jam1: in the test itself a new server as root is created | 09:49 |
| jam1 | TheMue: I still don't see what is *ipv6* related about that code | 09:50 |
| axw | wallyworld__: http://paste.ubuntu.com/7741178/ :( | 09:50 |
| TheMue | jam1: we yesterday discussed if then later we’ll parameterize this test to run once for IPv4 only and once for IPv6 addresses | 09:50 |
| wallyworld__ | looking | 09:50 |
| TheMue | jam1: so far only building ::1:port as address | 09:51 |
| wallyworld__ | axw: is that with trunk? | 09:51 |
| axw | wallyworld__: yep | 09:51 |
| wallyworld__ | :-( | 09:52 |
| axw | wallyworld__: oh wait. I did make a modification... *possibly* related | 09:52 |
| TheMue | jam1: IMHO simply to allow testing without touching the current TestAddRemoveSet | 09:52 |
| axw | wallyworld__: I'll let you know if I repro on trunk | 09:52 |
| axw | for now, ignore me | 09:52 |
| wallyworld__ | ok :-) | 09:53 |
| jam1 | TheMue: fwiw, I'd rather see the functions collapsed into ones that take a root (which might be self.root) rather than duplicated. | 09:53 |
| jam1 | TheMue: similarly, if the only difference for TestAddRemoveSetIPv6 is that we are using "::1" as addresses, that sounds like something that could be pulled into common code. | 09:54 |
| TheMue | jam1: as I wrote above, that’s the goal. this code is simply a intermediate test bed | 09:55 |
| TheMue | jam1: it shall be combined later | 09:56 |
| jam1 | TheMue: ah, I missed that line, hard to catch everything with a couple distractions and other conversations going on :) | 09:56 |
| TheMue | jam1: yeah, know that feeling. multiple discussion here and in parallel via mail while digging in own code or docs. sadly we haven’t implemented internal goroutines | 09:57 |
| TheMue | jam1: regarding the docs it seems to be not simple to place them on j.u.c. the web team already wanted them on help.u.c and is also planning a docs.u.c | 09:59 |
| jam1 | TheMue: we have 2 eyes, right? we should be able to follow at least 2 conversations at the same time. | 09:59 |
| TheMue | jam1: nick is already frustrated. I’m happy that at least GH renders markdown so that we can point interested users there | 09:59 |
| TheMue | jam1: *lol* just imagined how the eyes look (like in comics) when trying that :D | 10:00 |
| wallyworld__ | c7z: mgz: meeting? | 10:03 |
| davecheney | i thought there was a team meeting at 8 tongiht ? | 10:03 |
| davecheney | that is, now | 10:03 |
| wallyworld__ | davecheney: not today | 10:03 |
| davecheney | or is that only once every blue moon | 10:03 |
| c7z | wallyworld__: thanks | 10:03 |
| wallyworld__ | davecheney: this week it's at 5am for us | 10:03 |
| wallyworld__ | it rotate over 3 slots | 10:04 |
| davecheney | um, yeah, nope | 10:04 |
| davecheney | have fun at your leadership cabal | 10:04 |
| davecheney | voidspace: did i read that mongo can't listen on ipv6 in repl mode ? | 10:06 |
| TheMue | davecheney: it seems more to be a problem with the address notation and also with localhost | 10:06 |
| davecheney | hmmm | 10:07 |
| TheMue | davecheney: voidspace is currently investigating | 10:07 |
| TheMue | davecheney: they cannot parse [::1]:port | 10:07 |
| TheMue | davecheney: fixed with 2.7 | 10:07 |
| jam1 | davecheney: it appears to be able to listen, but it does'nt support [] syntax for disambiguating : | 10:07 |
| jam1 | TheMue: actually, not fixed yet | 10:08 |
| jam1 | but *if* fixed, not until 2.7 | 10:08 |
| TheMue | jam1: ok, thought 2.7 is available at least as developer release | 10:08 |
| davecheney | crap | 10:08 |
| jam1 | TheMue: I just checked out the github source and it isn't fixed there | 10:09 |
| davecheney | trusty ships with 2.4 | 10:09 |
| TheMue | jam1: *hmpf* | 10:09 |
| davecheney | so we'll be back to shipping things via the cloud archive again | 10:09 |
| jam1 | TheMue: so the issue is that we have to use ":dead:beef:17017" and just always specify :PORT at the end | 10:09 |
| mwhudson | 2.7 is the unstable release series | 10:10 |
| mwhudson | (of mongo) | 10:10 |
| TheMue | jam1: but this also works with 2.4.* | 10:10 |
| mwhudson | so you guys won't get to use any fix until 2.8 is released | 10:10 |
| TheMue | jam1: ? | 10:10 |
| davecheney | jam1: that isn't a valid ipv6 address, http://play.golang.org/p/mtv1LPeghP | 10:10 |
| mwhudson | (not that it seems this bug actually matters to you guys) | 10:10 |
| TheMue | davecheney: not? ;) | 10:11 |
| jam1 | davecheney: no, what I typed was not valid, just psuedocode | 10:11 |
| davecheney | i think it needs some more [ ] 's | 10:11 |
| davecheney | http://play.golang.org/p/YRQ47sr6fB | 10:11 |
| davecheney | from memory | 10:11 |
| jam1 | davecheney: so the issue is... we can write it correctly in our code as http://play.golang.org/ | 10:12 |
| jam1 | sorry: http://play.golang.org/p/srNH2QbtR3 | 10:12 |
| jam1 | davecheney: but when we configure the replicaset information | 10:12 |
| jam1 | mongo actually trnsforms [::1]:17017 into ::1:17017 internally | 10:12 |
| jam1 | and looks to see if it knows about the addresses you are passing in. | 10:12 |
| jam1 | so when we tell mongo about other mongod's, we have to give it the "invalid" form | 10:12 |
| davecheney | that's pants | 10:13 |
| jam1 | we still dial [::1]:17017 | 10:13 |
| davecheney | yeah | 10:13 |
| perrito666 | good morning juju people | 10:18 |
| davecheney | o/ | 10:18 |
| jam1 | morning perrito666 | 10:19 |
| voidspace | perrito666: morning | 10:25 |
| voidspace | jam1: note about your comments earlier | 10:31 |
| voidspace | jam1: I *really* wasn't intending to leave the ipv6 tests as just copy-pasted versions of the original | 10:32 |
| voidspace | jam1: I started with copy-pasta so I could tinker with just the ipv6 version before re-combining them | 10:32 |
| jam1 | voidspace: I understand, I was just looking at it and going... there doesn't seem to be anything ipv6 in here. | 10:32 |
| voidspace | jam1: TheMue asked me to push what I had so far, so I did... | 10:33 |
| voidspace | jam1: both the test and the inititiate function can be collapsed back together and parameterised | 10:33 |
| jam1 | I have to say, my proficiency reading C++ has gone down significantly in 8 years of working only in python and go :) | 10:34 |
| voidspace | heh, not really a surprise | 10:34 |
| jam1 | all those mysterious namespaced functions | 10:34 |
| jam1 | where is this "host()" defined that you are calling :) | 10:34 |
| voidspace | my C++ skills are as sharp as they've ever been :-) | 10:38 |
| TheMue | voidspace: yes, your pushed branch helps me to get better into the discussion | 10:38 |
| voidspace | TheMue: good, it's just not a finished article | 10:39 |
| TheMue | voidspace: my C++ skills too, below 0 | 10:39 |
| voidspace | :-) | 10:39 |
| voidspace | TheMue: I hope I've fixed it now - just waiting for test | 10:39 |
| TheMue | voidspace: great | 10:39 |
| voidspace | we'll see | 10:39 |
| vladk | dimitern: does it make sense? https://github.com/juju/juju/pull/237 | 10:41 |
| jam1 | vladk: dimitern: TheMue: voidspace: standup | 10:44 |
| TheMue | jam1: oh, almost forgotten, in vladks PR | 10:45 |
| jam1 | vladk: poke ? | 10:47 |
| vladk | jam1: just a second | 10:47 |
| davecheney | http://juju-ci.vapour.ws:8080/job/github-merge-juju/367 | 10:54 |
| davecheney | did the jenkins machine go away ? | 10:54 |
| c7z | davecheney: looking | 10:55 |
| c7z | davecheney: looks fine to me, just has test build failure: | 10:56 |
| c7z | # github.com/juju/juju/state/apiserver_test state/apiserver/server_test.go:138: cannot use stm.Tag().String() (type string) as type names.MachineTag in function argument state/apiserver/server_test.go:150: cannot use stm.Tag().String() (type string) as type names.MachineTag in function argument FAILgithub.com/juju/juju/state/apiserver [build failed] | 10:56 |
| davecheney | ok, i'll fix that | 10:56 |
| davecheney | i cna't reach the build machine atm | 10:56 |
| davecheney | oh well | 10:56 |
| davecheney | it's after stumps anyway | 10:56 |
| c7z | davecheney: can you access it by IP? 54.86.142.177 | 10:57 |
| wwitzel3 | hola | 10:57 |
| voidspace | wwitzel3: morning | 10:58 |
| TheMue | wwitzel3: o/ | 10:58 |
| wwitzel3 | voidspace, TheMue: morning | 10:59 |
| wwitzel3 | jam1: you have a bit to chat about your review comments on #234 (removing the state dep from environs) | 11:00 |
| wwitzel3 | jam1: mainly, I believe you .. I'm just not sure how to go about doing that :) | 11:00 |
| alexisb | jam1, ping | 11:03 |
| jam1 | alexisb: just finishing up our standup, brt | 11:03 |
| voidspace | jam1: just got the ipv6 replicaset test passing, will refactor and submit PR | 11:11 |
| voidspace | jam1: just FYI... | 11:12 |
| TheMue | voidspace: \o/ also here again | 11:12 |
| voidspace | :-) | 11:12 |
| jam1 | wwitzel3: so it is a route that we've wanted to go, and I can at least outline it for you. | 11:12 |
| jam1 | but basically, we've already done all the work to know what address the bootstrap machine has to ssh into it and set itup. | 11:12 |
| jam1 | if the last step of bootstrap was to connect to the API using the address that we already know about | 11:13 |
| jam1 | then I think we could drop all of the fallback code, and simplify a lot of stuff. | 11:13 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| TheMue | voidspace: i’m available for next chat in a few moments, just moving into the garden, weather is too fine | 11:38 |
| voidspace | TheMue: sure | 11:45 |
| TheMue | voidspace: so, sitting on the veranda | 11:47 |
| TheMue | voidspace ;) | 11:47 |
| TheMue | voidspace: if I’m right we’ve got two cards left | 11:49 |
| === liam_ is now known as Guest45753 | ||
| TheMue | voidspace: peer grouper, dummy privider, and oh, lxc templates. is it new or did I missed that one? | 11:51 |
| wallyworld__ | jam1: wanna come back to team leads hangout? | 11:54 |
| === urulama-away is now known as urulama | ||
| voidspace | TheMue: we missed discussing that yesterday | 12:00 |
| voidspace | TheMue: that sounds like a fun one to pick up | 12:00 |
| voidspace | TheMue: I'm going to finish refactoring this test, submit a PR and then go on lunch | 12:00 |
| voidspace | TheMue: and then sync up with you | 12:00 |
| TheMue | voidspace: sounds like a plan o/ | 12:01 |
| voidspace | cool | 12:01 |
| === psivaa is now known as psivaa-lunch | ||
| bodie_ | morning all | 12:05 |
| wwitzel3 | morning bodie_ | 12:05 |
| jam1 | wwitzel3: so it looks like wallyworld__ also has a stake in fixing the state.Info stuff (he wants to get rid of the bootstrap-state file because of complexities wrt in-environment storage{) | 12:10 |
| jam1 | so I just had a chat with him, and he's going to put it on the agenda for the sprint next week. | 12:10 |
| wallyworld__ | wwitzel3: we can do it together :-) | 12:11 |
| === psivaa-lunch is now known as psivaa | ||
| voidspace | TheMue: https://github.com/juju/juju/pull/238 | 13:00 |
| TheMue | voidspace: *click* | 13:01 |
| voidspace | :-) | 13:01 |
| TheMue | voidspace: LGTM, nice idea with the address handling | 13:06 |
| voidspace | TheMue: cool, thanks | 13:08 |
| voidspace | TheMue: what would you call it instead of getAddr? | 13:08 |
| TheMue | voidspace: simply address | 13:09 |
| voidspace | TheMue: I agree in general "get" is unnecessary for getter methods - but this isn't a getter method | 13:09 |
| voidspace | TheMue: heh, I think that's less descriptive | 13:09 |
| TheMue | voidspace: serverAddress | 13:09 |
| voidspace | but matter of taste I guess | 13:09 |
| voidspace | that's not bad | 13:09 |
| TheMue | voidspace: I’m afk for a few moment, then we can have our chat | 13:10 |
| voidspace | TheMue: I'm about to go on lunch - so after that I'll catch up with you | 13:13 |
| voidspace | TheMue: dang, I get a test failure so not merging yet | 13:14 |
| voidspace | TheMue: the *non* ipv6 variant fails | 13:14 |
| sinzui | jam, cmars: I would like your opinion in the "Options for releasing 1.20.0 which is stalled" thread in your email. | 13:19 |
| cmars | sinzui, looking now | 13:19 |
| cmars | sinzui, i'm +1 for "release HA as an 'experimental tech preview'" | 13:21 |
| sinzui | cmars, I think you mean restoration of HA state-server is experimental | 13:22 |
| cmars | sinzui, my mistake, yes, backup/restore | 13:22 |
| wwitzel3 | wallyworld__: sounds good :) | 13:25 |
| fwereade | wwitzel3, ping | 13:25 |
| wwitzel3 | fwereade: pong | 13:25 |
| fwereade | wwitzel3, LoadState/SaveState -- complexity/ugliness? | 13:26 |
| wallyworld__ | fwereade: i'm off to bed, can you discuss with jam1 also | 13:26 |
| fwereade | wallyworld__, maybe -- jam1, to what is wallyworld__ alluding? 1.20? | 13:27 |
| wallyworld__ | fwereade: he indicated that only the client needs it, and we can modify bootstrao to cahce addresss so we don't need the stte file | 13:27 |
| fwereade | wallyworld__, ah, ok, I see | 13:27 |
| wallyworld__ | fwereade: i'm talking about the load/save state stuff | 13:27 |
| fwereade | jam, I am kinda -1 on that: ISTM that LoadState/SaveState work perfectly, and I don't see how we're having to do any extra work to maintain the ability to look up an environment from scratch without a cached address | 13:28 |
| fwereade | jam, cos addresses *do* change | 13:28 |
| wwitzel3 | fwereade: to answer your question .. no idea, haven't looked | 13:29 |
| fwereade | jam, if we're really making things *that* much simpler/cleaner by dropping the feature I could maybe be swayed | 13:29 |
| fwereade | wwitzel3, ah, there was a mail claiming you were having trouble with LoadState/SaveState in the environ/state dependency-munging | 13:29 |
| voidspace | TheMue: I'm going to look at this after lunch, I need a break | 13:29 |
| fwereade | wwitzel3, AFAICS we should keep those funcs, and keep on using them internally to discover state server addresses in the providers that have storage | 13:30 |
| fwereade | wwitzel3, the really nasty stuff around those -- the flagrant layering violations by which we had jujud of all things depending on them -- is I think gone already | 13:31 |
| wwitzel3 | fwereade: well, I didn't make any effort to refactor them? Maybe that was the issue :) | 13:31 |
| voidspace | TheMue: actually, I seem to have fixed it :-o | 13:31 |
| fwereade | wwitzel3, so they're just a common chunk of code, useful for providers that implement storage, and unless they're actively causing trouble we should just leave them alone | 13:31 |
| fwereade | wwitzel3, the only refactoring required AFAIK is making the state-file path *either* private *or* a param | 13:32 |
| fwereade | wwitzel3, although I think I'd favour private | 13:32 |
| fwereade | wwitzel3, and even that is totally orthogonal to what you're actually doing anyway | 13:33 |
| wwitzel3 | fwereade: I'm completely lost atm and feel like i've miss a piece of this converstaion somewhere. | 13:33 |
| wwitzel3 | sorry :/ | 13:33 |
| voidspace | on that note | 13:33 |
| * voidspace really goes on lunch | 13:33 | |
| wwitzel3 | does the LoadState/SaveState stuff related to the comments about StateInfo on the review? | 13:34 |
| wallyworld__ | fwereade: the issue as i understood it was it complicated removing state as a dependency of environ due to shared use of the state.Info, and if Load/SaveState were gone, that dependency would go with it | 13:34 |
| fwereade | wwitzel3, I don;t think you need to worry, I can fight it out with jam in-thread :) | 13:34 |
| fwereade | wallyworld__, I think Load/SaveState are irrelevant | 13:34 |
| wwitzel3 | fwereade: it probably doesn't help I haven't checked my email yet | 13:35 |
| fwereade | wallyworld__, they're an implementation detail | 13:35 |
| wwitzel3 | I've only read the review comments. | 13:35 |
| fwereade | wallyworld__, the StateInfo method usually uses those under the hood | 13:35 |
| wallyworld__ | wwitzel3: jam mentioned that removing load/save state would make your refactoring easier in a review comment | 13:35 |
| wallyworld__ | if i recall recorrectly | 13:35 |
| wwitzel3 | wallyworld__: ok, I was going to follow-up on that comment because I had no idea what the "fallback code" was. | 13:36 |
| fwereade | wallyworld__, jam: is it really in any way hard/complex to have an environs.Environ be able to return the addresses of its state servers? | 13:36 |
| wwitzel3 | wallyworld__: so if the fallback code is Load/Save State, and that is related to the Info struct, then I'm mostly caught up I think. | 13:36 |
| fwereade | wallyworld__, jam: we tell the environ when it's starting a state server | 13:36 |
| TheMue | voidspace: great that it’s fixed and enjoy your lunch | 13:36 |
| wallyworld__ | wwitzel3: as i understand it yes | 13:36 |
| wwitzel3 | wallyworld__: thanks, sometimes I just need my hand held | 13:37 |
| fwereade | wallyworld__, jam: is it so much to ask that it record which ones are state servers, for the convenience of the bootstrap users? | 13:37 |
| wallyworld__ | wwitzel3: me too, it make me feel safe :-) | 13:37 |
| wwitzel3 | :) | 13:37 |
| fwereade | wallyworld__, jam: to be fair, we would occasionally want to update it in an ideal world, when a state server gets demoted | 13:38 |
| wallyworld__ | fwereade: i think the issue is not that we ask the environ to do it, but that it not use cloud storage for it | 13:38 |
| wallyworld__ | if we can break that link, things become simpler | 13:38 |
| fwereade | wallyworld__, jam: we have provider storage already implemented in all these cases, though | 13:38 |
| fwereade | wallyworld__, jam: I don't think so | 13:38 |
| fwereade | wallyworld__, jam: asking the Environ for the storage inside the state server becomes incoherent, it's true | 13:39 |
| fwereade | wallyworld__, jam: but that's independenyt | 13:39 |
| wallyworld__ | fwereade: it's implemented now, but new providers without storage are difficult | 13:39 |
| wallyworld__ | and the use case is - clients need to connect, the last api address they had doesn't work, where do they get another from to try | 13:39 |
| fwereade | wallyworld__, jam: the environ's responsible for knowing what its state servers are -- I don't really believe we actually have any providers that don't allow *some* way of tagging the state servers | 13:39 |
| wallyworld__ | if we properly cached the addresses in jenv, then we don't need to query state file | 13:40 |
| wallyworld__ | we save the last connected one, but not the others | 13:40 |
| wallyworld__ | it's about the client connecting, not the environ knowing | 13:41 |
| wallyworld__ | ideally there would be no provider code in the client | 13:41 |
| fwereade | wallyworld__, how do you propose one bootstraps a new state server? I really don't think we want a separate tool for that... | 13:42 |
| fwereade | wallyworld__, I agree we want better caching | 13:42 |
| wallyworld__ | yeah bootstrap needs provider code | 13:42 |
| wallyworld__ | but would be nice to minimise it | 13:42 |
| fwereade | wallyworld__, but I don't yet see a good reason to drop the fallback code -- we would hopefully hardly ever need it, it's true | 13:42 |
| wallyworld__ | if we drop it, it makes it easier to divorce state from environ, and remove need for provider storage | 13:43 |
| fwereade | wallyworld__, completely disagree | 13:43 |
| wallyworld__ | we can use env blob storage instead | 13:43 |
| wallyworld__ | see wwitzel3's branch and jam's comment | 13:44 |
| fwereade | wallyworld__, we can and will always use env blob storage for everything -- but if you internally implement the environ Storage interface, you can use it with L/SState and the fallback stuff continues to Just Work | 13:44 |
| fwereade | wallyworld__, that particular file happens to be in "env" storage, but it's not really for the env's use at all, it's for the client's -- and I don't see how the env storage change needs to actually impact it | 13:45 |
| wallyworld__ | that was my original thought but jam was quite certain we should or could drop it | 13:45 |
| wallyworld__ | fwereade: ah because | 13:45 |
| wallyworld__ | the client needs to access the api to get the blob storage | 13:46 |
| wallyworld__ | but it uses the state file to get the api to connect to | 13:46 |
| wallyworld__ | s/api/address | 13:46 |
| wallyworld__ | catch 22 | 13:46 |
| fwereade | wallyworld__, the client shouldn't need to use the blob storage directly, should it? | 13:46 |
| wallyworld__ | no, that's the point | 13:46 |
| wallyworld__ | the client needs state file if address it has doesn't work | 13:47 |
| wallyworld__ | it currently talks to cloud storage directly to get it | 13:47 |
| fwereade | wallyworld__, and the *client* will not need any direct knowledge of the state file either -- because an environ doesn't *have* to use that mechanism in the first place | 13:47 |
| wallyworld__ | if we move state file to blob storage, client can't get to it | 13:47 |
| wallyworld__ | when it needs to | 13:47 |
| fwereade | wallyworld__, we certainly shouldn't do that | 13:48 |
| fwereade | wallyworld__, the state file is an *detail* of certain provider *implementations* | 13:48 |
| wallyworld__ | which the client uses directly when needed because the whol epoint it that there's no api to connect to | 13:49 |
| wallyworld__ | because the address the client has is not working | 13:49 |
| fwereade | wallyworld__, sorry, I'm keeping you up, but I am happy to continue arguing this out if you're really of a mind to... | 13:49 |
| fwereade | wallyworld__, I feel like we're talking past each other though | 13:50 |
| wallyworld__ | fwereade: should we take this toa hangout? | 13:50 |
| fwereade | wallyworld__, if you're free, let's | 13:50 |
| fwereade | wallyworld__, tanzanite? | 13:50 |
| wallyworld__ | https://plus.google.com/hangouts/_/canonical.com/tanzanite-daily | 13:50 |
| perrito666 | niemeyer: hey, are you around? | 13:54 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| niemeyer | perrito666: I am | 14:05 |
| niemeyer | perrito666: In a call, though | 14:05 |
| jamespage__ | dimitern, fwereade? | 14:05 |
| wwitzel3 | perrito666, ericsnow: I'm running a bit behind on standup, be there shortly (in another call) | 14:05 |
| jamespage__ | coming :-) ? | 14:05 |
| niemeyer | perrito666: What's up? Will be with you soon | 14:05 |
| dimitern | jamespage__, sorry, brt | 14:05 |
| fwereade | jamespage__, hell, other meeting running over | 14:05 |
| ericsnow | wwitzel3: np | 14:05 |
| perrito666 | niemeyer: ouch, I was tying to lure you into another call for a moment :p | 14:07 |
| TheMue | voidspace: sh.., TestAddRemoveSetIPv6 is failing /o\ | 14:10 |
| TheMue | voidspace: „couldn't initiate : can't find self in the replset config my port: 35060“ | 14:11 |
| c7z | rick_h__: (or a delegee) I've got a a bunch of jenkins-github-lander changes to land, first one up here: <https://github.com/juju/jenkins-github-lander/pull/13/files> | 14:15 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| voidspace | TheMue: how annoying | 14:46 |
| voidspace | TheMue: passes for me :-/ | 14:46 |
| voidspace | TheMue: it may be a problem running on a slower machine perhaps | 14:47 |
| rogpeppe | fwereade: is it possible to have a charm resource that's not associated with a particular series? | 14:47 |
| voidspace | TheMue: it takes two minutes to run, but it passes consistently for me | 14:57 |
| TheMue | voidspace: strange | 14:58 |
| TheMue | voidspace: I hate timing problems | 14:58 |
| TheMue | voidspace: is there a way to define a different retry behavior? | 14:58 |
| voidspace | TheMue: trying again in case it's spurious | 14:58 |
| voidspace | TheMue: the other possibility is that this is precise. *Or* it's a machine without an ipv6 stack. | 14:59 |
| voidspace | TheMue: this is the first ipv6 dependent test in juju-core, right? | 14:59 |
| TheMue | voidspace: that’s what I thought first too, the missing IPv6 | 14:59 |
| voidspace | TheMue: ah | 14:59 |
| TheMue | voidspace: yep | 14:59 |
| voidspace | TheMue: I didn't bump the gittesting revision number in dependencies.tsv | 15:00 |
| voidspace | that will be the problem | 15:00 |
| voidspace | grabbing coffee then fixing | 15:00 |
| TheMue | voidspace: hehe, when it’s that simple than it’s fine | 15:00 |
| fwereade | rogpeppe, I think a resource is always acssociated with a specific charm, and last I heard we were pretty solidly committed to having a single charm be a single series | 15:18 |
| fwereade | rogpeppe, so yes, but it's implicit rather than explicit | 15:18 |
| fwereade | rogpeppe, er, so, the answer to your posed question is actually *no* | 15:19 |
| fwereade | rogpeppe, but there's no explicit association between a resource and a series, it's implicit in the association between a resource and a charm | 15:19 |
| rogpeppe | fwereade: so there's an association with a resource and a series because you can't specify a resource without specifying a fully qualified charm name including the series, right? | 15:23 |
| fwereade | rogpeppe, yeah | 15:24 |
| rogpeppe | fwereade: specifically, it would be nice to know if this looks sane: https://docs.google.com/a/canonical.com/document/d/1ILHRpOe-qDlmjxHBbLUea7InDpehx5_roJ1ynZmcZDc/edit (search for "resources") | 15:24 |
| perrito666 | niemeyer: what I needed is for you to talk a moment with gsamfira about adding a few things to gocheck to make it more windows friendly, so let us know if you have a moment so we can talk about the patch he proposes | 15:26 |
| jcw4 | hi fwereade; jam1 had a great comment on https://github.com/juju/juju/pull/216 and I'd like to get your thoughts... you'd need to look at the diff though since I changed it in response to your review yesterday. | 15:28 |
| fwereade | rogpeppe, jcw4, I'm queuing tabs for you both, hope I will pop enough from my stack to get to them soon | 15:29 |
| rogpeppe | fwereade: ta! | 15:29 |
| jcw4 | fwereade: lol, thanks :) | 15:29 |
| mfoord | TheMue: ok, updated dependency and resolved resulting conflict (!?!) | 15:40 |
| mfoord | TheMue: waiting on the bot - I think it's probably running the old revision again unfortunately | 15:41 |
| === vladk is now known as vladk|offline | ||
| TheMue | mfoord: doesn’t it always starts from zero, so retrieving all dependencies based on the dependencies file? | 15:42 |
| mfoord | TheMue: I mean that I initially thought the problem was a spurious timing related one | 15:42 |
| mfoord | TheMue: so I added another $$merge$$ comment which the bot picked up | 15:43 |
| mfoord | TheMue: so I think it's running tests from before I updated the dependencies | 15:43 |
| TheMue | mfoord: ah, ok | 15:43 |
| mfoord | TheMue: so I need to wait for that to fail so I can retry the merge a third (and hopefully final) time | 15:43 |
| mfoord | TheMue: did you start looking at lxc templates? | 15:44 |
| TheMue | mfoord: the latest one had a panic during build? | 15:44 |
| TheMue | mfoord: only a short look, mostly I’m writing on the API spec | 15:44 |
| mfoord | ah, ok | 15:44 |
| TheMue | mfoord: but we can talk about, my brain needs a little distraction from the API stuff | 15:45 |
| mfoord | TheMue: I don't know what the panic is about, but the previous test failed again for the same reason | 15:45 |
| mfoord | and that at least is fixed now | 15:46 |
| mfoord | TheMue: ok, let's talk in two minutes | 15:46 |
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| fwereade | rogpeppe, the api proposal is slightly difficult for me to map onto the action of juju publish -- is there another doc that covers that? if not, I think that needs to be defined before we can reasonably judge an api proposal | 15:53 |
| mfoord | TheMue: ok, I'm ready - hangout? | 15:53 |
| rogpeppe | fwereade: juju publish is, I believe, just the action of POSTing a new charm to the store, right? | 15:55 |
| fwereade | rogpeppe, I think it also needs to do resources | 15:56 |
| fwereade | rogpeppe, either charm+resources, or charm alone, or resources alone | 15:56 |
| rogpeppe | fwereade: they're independent things then? | 15:57 |
| katco | is there a reason that there's one function in this file all by its lonesome? github.com/juju/juju/upstart/service.go. can i roll this into upstart.go? | 15:57 |
| fwereade | rogpeppe, and we need to figure out how we update the (charm-rev, resources-rev) pairs that define the "current" version of a charm(+resources) | 15:57 |
| rogpeppe | fwereade: so they have two independent endpoints (/archive and /resources) | 15:57 |
| rogpeppe | fwereade: the version is updated automatically and returned in the post response | 15:57 |
| rogpeppe | fwereade: at least, that's the current plan - perhaps there's a reason that's not good? | 15:58 |
| fwereade | rogpeppe, doesn't a resources revision refer to a list of N files? | 15:58 |
| sinzui | katco, what TZ are you in. I saw you at my midnight last night, and now I see you at my Noon | 15:58 |
| katco | sinzui: GMT -6. little known fact, i am actually a robot. | 15:58 |
| rogpeppe | fwereade: yes, but the revision is incremented any time one of those files is uploaded | 15:59 |
| rogpeppe | fwereade: so the result is the same, i *think* | 15:59 |
| fwereade | rogpeppe, I don't think that makes sense | 15:59 |
| rogpeppe | katco: aren't we all | 15:59 |
| katco | :p | 16:00 |
| katco | beep boop | 16:00 |
| fwereade | rogpeppe, if two files need to match, and we inc rev every time one is uploaded, we end up with a whole bunch of broken resource-stream revisions | 16:00 |
| rogpeppe | fwereade: i'm not sure what you mean by "two files need to match" | 16:00 |
| fwereade | rogpeppe, ok, even simpler | 16:02 |
| sinzui | katco, wgrant was suspected of being a robot until we discovered we couldn't put him into an N-1 configuration | 16:02 |
| fwereade | rogpeppe, one version of a charm defines resources a, b, c; another defines d, e | 16:02 |
| sinzui | Sleep gives you cancer anyway. | 16:02 |
| katco | sinzui: lol | 16:02 |
| fwereade | rogpeppe, how does the POST approach work? | 16:03 |
| rogpeppe | fwereade: resources? streams? filenames? | 16:03 |
| rogpeppe | fwereade: i thought resources weren't associated with a specific version of a charm? | 16:03 |
| fwereade | rogpeppe, sorry, just a mo | 16:04 |
| katco | process question: if i merged a partial-fix in under a branch, should i do the rest of the work in a different branch, or in the same branch w/ a new PR? | 16:09 |
| c7z | katco: new branch | 16:10 |
| c7z | well, depends exactly what you mean by partial | 16:10 |
| c7z | but if it's landed, you should just take a new checkout of trunk (including that change) for your followup | 16:11 |
| katco | c7z: specifics: log perms are wrong. i fixed 1 class of log, working on remaining class. | 16:11 |
| katco | c7z: but the bug is for all log perms | 16:11 |
| mfoord | TheMue: http://containerops.org/2013/11/19/lxc-networking/ | 16:11 |
| katco | c7z: it has landed, but i can just rebase the branch from trunk. the naming nomenclature i'm using lends itself to doing the remaining work in this same branch, but i wasn't sure if there were downsidexz | 16:12 |
| katco | *downsides | 16:12 |
| c7z | you want a new pr, so it's easiest with a fresh branch | 16:13 |
| katco | c7z: ok, ty! | 16:13 |
| === vladk is now known as vladk|offline | ||
| sinzui | wwitzel3, perrito666 : Do either of you have a moment to review https://github.com/juju/juju/pull/240 | 16:19 |
| c7z | state/api/client.go:// TODO(axw) 2014-04-11 #XXX | 16:20 |
| c7z | ace :) | 16:20 |
| niemeyer | perrito666: Hi | 16:28 |
| niemeyer | perrito666: Sure | 16:28 |
| niemeyer | perrito666: Any time | 16:28 |
| === hatch__ is now known as hatch | ||
| jrwren | juju local mongodb grows to 6.5GB rather fast, how much does a tiny juju local need? | 16:49 |
| niemeyer | jrwren: I suppose the usual flags for reducing pre-allocatoin are not being used? | 16:54 |
| niemeyer | jrwren: --smallfiles --noprealloc etc | 16:54 |
| jrwren | those are used. | 16:54 |
| niemeyer | jrwren: How come it grows to 6.5G then? | 16:54 |
| jrwren | that is what I'm asking :) | 16:54 |
| niemeyer | jrwren: Should be easy to see what's inside the database | 16:55 |
| fwereade | rogpeppe, sorry, meeting is taking a while :/ | 16:59 |
| rogpeppe | fwereade: np | 16:59 |
| rogpeppe | fwereade: although i will be stopping soon | 16:59 |
| wwitzel3 | sinzui: LGTM | 16:59 |
| perrito666 | niemeyer: do you have a moment now to jump into a hangout? | 17:02 |
| niemeyer | perrito666: Yep | 17:02 |
| perrito666 | niemeyer: https://plus.google.com/hangouts/_/canonical.com/cloudbase?authuser=3 | 17:02 |
| perrito666 | lemme know if it does not work I will issue an invite | 17:02 |
| sinzui | thank you wwitzel3 | 17:03 |
| niemeyer | perrito666: | 17:03 |
| niemeyer | "This party is over..." | 17:04 |
| perrito666 | mm hangout lies a lot like that | 17:04 |
| niemeyer | Have never seen that one.. | 17:04 |
| perrito666 | do I invite you to your canonical email? | 17:04 |
| niemeyer | perrito666: Ahh, it's the authuser part | 17:04 |
| niemeyer | perrito666: That's your user.. the link isn't valid for me.. fixed it by hand | 17:04 |
| fwereade | rogpeppe, hmm, on rereading that mail it's about *next* week, so we're not meeting about resources this evening as I was expecting | 17:10 |
| fwereade | rogpeppe, I'm going to have to drop off very shortly myself | 17:10 |
| rogpeppe | fwereade: ha | 17:10 |
| rogpeppe | fwereade: we're chatting in a hangout if you wanted a quick chat | 17:10 |
| fwereade | rogpeppe, but mainly I am still not understanding how we can do the resource POSTing | 17:10 |
| rogpeppe | fwereade: but i imagine you're pooped :-) | 17:10 |
| rogpeppe | fwereade: yeah, i'm pretty fuzzy over the whole thing now myself | 17:11 |
| fwereade | rogpeppe, I'm fine but I will not be popular if I'm online for more than 10 mins | 17:11 |
| rogpeppe | :-) | 17:11 |
| fwereade | rogpeppe, what hangout? | 17:11 |
| rogpeppe | fwereade: https://plus.google.com/hangouts/_/canonical.com/daily-standup?authuser=1 | 17:11 |
| === psivaa is now known as psivaa-afk | ||
| jcw4 | c7z, mgz http://juju-ci.vapour.ws:8080/job/github-merge-juju/373/console ? InvalidInstanceID? | 17:27 |
| c7z | looking | 17:28 |
| c7z | seems like ec2 flakiness | 17:28 |
| perrito666 | :q | 17:29 |
| jcw4 | just $$merge$$ again? | 17:29 |
| perrito666 | sorry, wrong window | 17:29 |
| jcw4 | :) | 17:29 |
| c7z | I've hit rebuild there | 17:29 |
| jcw4 | c7z: ta | 17:29 |
| jcw4 | mgz: that worked, thanks! | 17:50 |
| menn0 | anyone joining the core team meeting? | 18:03 |
| * perrito666 has been connected to some form of hangout the whole day | 18:11 | |
| fwereade | wwitzel3, katco: https://plus.google.com/hangouts/_/canonical.com/juju-core-team?authuser=1 | 18:13 |
| alexisb | wwitzel3, katco ^^^ | 18:13 |
| fwereade | mgz, it's probably late for you? | 18:13 |
| katco | alexisb: sorry, i'm in! is there an invite or something i need to be added to? | 18:20 |
| alexisb | katco, yes, let me get you added | 18:21 |
| katco | alexisb: ty :) | 18:22 |
| alexisb | cmars, just fyi, we are having a team call if you are available | 18:30 |
| alexisb | I assume your team is done for the day | 18:30 |
| perrito666 | fwereade: you seem to have frozen | 18:33 |
| === vladk|offline is now known as vladk | ||
| fwereade | cmars, ping | 18:36 |
| alexisb | anyone know if thumper is going to be online today? | 19:08 |
| alexisb | menn0, waigani ^^ | 19:09 |
| waigani | alexisb: morning :) | 19:09 |
| menn0 | alexisb: he was sick yesterday so not sure | 19:09 |
| mfoord | g'night all | 19:09 |
| alexisb | morning waigani | 19:10 |
| alexisb | btw, did you see the video link I posted the other day? | 19:10 |
| alexisb | the one that reminded me of you | 19:10 |
| perrito666 | could someone PTAL https://github.com/juju/testing/pull/18 ? | 19:32 |
| === vladk is now known as vladk|offline | ||
| === vladk|offline is now known as vladk | ||
| === vladk is now known as vladk|offline | ||
| bac | sinzui: your release notes for 1.20 are amazingly thorough and informative. thanks! | 19:51 |
| sinzui | bac: thank you | 19:52 |
| perrito666 | sinzui: you do know that we eventually will build you a monument and worship it before each release for our tests to pass, right? | 19:55 |
| sinzui | perrito666, Ice cream will be fine | 19:55 |
| perrito666 | sinzui: given that I am about 15kkm from you I think a monument is much easier than sending you ice cream | 19:58 |
| sinzui | perrito666, :) | 19:59 |
| sinzui | I have a similar problem getting Aussie pies delivered to my house in the US | 19:59 |
| alexisb | alrighty all, I am off for a long weekend | 20:16 |
| jcw4 | have fun alexisb | 20:17 |
| alexisb | see everyone on monday! | 20:17 |
| wwitzel3 | have a good one alexisb | 20:17 |
| alexisb | those in the US enjoy your 4th! | 20:17 |
| === alexisb is now known as alexisb_vac | ||
| wwitzel3 | alexisb_vac: thanks you too | 20:18 |
| katco | alexisb_vac: ditto :) | 20:19 |
| jrwren | to where does a charm install? I want to make sure my hook changes were deployed correctly | 20:30 |
| katco | can anyone help me understand what this means? "godeps: "/home/kate/workspace/go/src/github.com/juju/cmd" is not clean; will not update" | 20:35 |
| katco | when running godeps -u dependencies.tsv | 20:35 |
| katco | i did a go clean, didn't seem to help | 20:35 |
| jcw4 | katco: do you have changes in the juju/cmd repository? | 20:35 |
| katco | jcw4: i do not | 20:36 |
| jcw4 | hmm; if you go to /home/kate/workspace/go/src/github.com/juju/cmd and do a straight git pull -u ? | 20:37 |
| katco | oh jees... i see my error. | 20:37 |
| katco | i was looking at juju/juju/cmd, not juju/cmd | 20:37 |
| katco | that gets just a bit confusing at times :p | 20:38 |
| jcw4 | katco: ah... that's easy to do | 20:38 |
| katco | ty for your help jcw4 :) | 20:39 |
| jcw4 | katco: yw :) | 20:39 |
| stokachu | in the api, what are the watchers used for? just a general overview | 20:56 |
| jcw4 | stokachu: in general watchers watch for changes to collections in the stateserver | 21:03 |
| jcw4 | stokachu: and send events to the consumers of the watchers | 21:04 |
| stokachu | jcw4, ah ok | 21:04 |
| stokachu | ive got another question about the ServiceDeploy api, there is a ServiceName and CharmUrl. is CharmUrl a requirement? | 21:06 |
| jcw4 | stokachu: I don't know much about that | 21:07 |
| stokachu | ok | 21:07 |
| jcw4 | thumper: o/ | 21:08 |
| thumper | morning jcw4 | 21:09 |
| stokachu | it looks like i can't just call ServiceDeploy(ServiceName='wordpress') | 21:09 |
| stokachu | i have to give it a charmurl | 21:09 |
| jcw4 | stokachu: yeah, looking at the code it seems like any kind of deployment does need the CharmUrl | 21:10 |
| stokachu | im guessing just doing 'juju deploy wordpress' has some checking for setting that if isn't provided | 21:10 |
| stokachu | haven't checked | 21:10 |
| jcw4 | stokachu: hmm; the name CharmUrl only appears in 3 non-test files, and they all seem to just assume it's set | 21:11 |
| stokachu | interesting | 21:11 |
| stokachu | the only complication i see with having to set the url everytime is that you're forced to pick either trusty or precise. some cases i just want it to deploy the latest charm | 21:13 |
| stokachu | which is the behavior of 'juju deploy X' | 21:13 |
| stokachu | im also not sure what the point of ServiceName is wrt ServiceDeploy if we require a charmurl | 21:14 |
| stokachu | {"RequestId":4,"Error":"charm url must include revision","Response":{}} | 21:16 |
| stokachu | if i pass 'cs:trusty/juju-gui' as the CharmUrl thats the response i get back | 21:17 |
| jcw4 | stokachu: I'm afraid most of my experience with juju is in the state back-end, not at all with charms :-/ | 21:18 |
| stokachu | thats cool | 21:18 |
| jcw4 | stokachu: github.com/juju/charm/url.go around line 102 shows the url parsing | 21:21 |
| jcw4 | stokachu: looks like you can use local: instead of cs: for the schema possibly | 21:21 |
| stokachu | yea thats for deploy from a local repo | 21:21 |
| jcw4 | stokachu: fwiw the revision seems to be set in the url by appending -<revision number> to the name | 21:23 |
| stokachu | yea that works but how do i find the revision via the api? | 21:24 |
| stokachu | or do i have to search the charmstore? | 21:24 |
| jcw4 | stokachu: oh, I see; I thought you were authoring a charm | 21:24 |
| stokachu | im querying the juju api to try and deploy one currently | 21:25 |
| jcw4 | stokachu: right you did say something to that effect earlier on | 21:25 |
| jcw4 | stokachu: are you trying to deploy it programatically or using `juju deploy` | 21:27 |
| stokachu | programatically | 21:27 |
| jcw4 | stokachu: and you're wanting to find the right charm url in your code rather than having it supplied by a user? | 21:28 |
| stokachu | yea | 21:29 |
| stokachu | so my routine basically is deploy(charm, dictionary_of_settings) | 21:29 |
| stokachu | containg ToMachineSpec etc | 21:30 |
| jcw4 | and 'charm' is a user friendly name, supplied by a user somehow, but not including the charm url | 21:30 |
| stokachu | yea so like deploy('mysql') | 21:30 |
| stokachu | would in turn call ServiceDeploy | 21:30 |
| jcw4 | stokachu: okay; so looking at the tests for ServiceDeploy it's clear the charm url is required and must be fully specified including revision. | 21:32 |
| jcw4 | stokachu: so you'd need to find how to query the charm store, given a friendly name and get back a charm url | 21:32 |
| jcw4 | stokachu: resolving possibly many results | 21:32 |
| stokachu | ok that works | 21:32 |
| stokachu | jcw4, im curious how just calling juju deploy mysql works then | 21:33 |
| stokachu | i thought it used the same api | 21:33 |
| jcw4 | stokachu: it does... juju/cmd/juju/common.go around line 58 is where it starts resolving the common name to a charm url | 21:35 |
| stokachu | ok reading that now | 21:36 |
| jcw4 | stokachu: it populates things like series from the environment | 21:36 |
| stokachu | i see the resolveCharmUrl but i dont see how it resolves the revision | 21:37 |
| jcw4 | stokachu: ah, there is a ResolveCharms method on the apiserver Client too | 21:37 |
| jcw4 | resolveCharmUrl uses that | 21:37 |
| jcw4 | and the apiserver/client defers that resolving to an implementor of the Repository interface | 21:38 |
| jcw4 | which I can't find an implementor in the juju repo | 21:40 |
| jcw4 | stokachu: but conceptually it seems to figure out an apropriate repostitory to query and then that repository returns a URL | 21:41 |
| stokachu | ok i think i understand the workflow now | 21:42 |
| stokachu | jcw4, thanks :) | 21:42 |
| jcw4 | stokachu: yw... one last comment; this seems helpful: http://juju-docs.readthedocs.org/en/latest/internals/charm-store.html#charm-revisions | 21:44 |
| stokachu | ah looks like there is some sort of REST within the charmstore i could utilize | 21:45 |
| davecheney | it's 8:30, about 10c in my house and i'm weargin hobo gloves -- #beautiful sydney | 22:33 |
| thumper | davecheney, waigani, menn0: it is the last day of the school term and my daughter has a guitar solo in assembly (starts in about 7 minutes) | 22:38 |
| thumper | I may be late for the standup | 22:38 |
| menn0 | thumper: no probs. That doesn't sound like something you should miss. | 22:38 |
| waigani | thumper: nice. My girl has a dance performance this afternoon! | 22:38 |
| davecheney | thumper: lets skip standup today then | 22:39 |
| davecheney | i'm fixing bugs | 22:39 |
| thumper | ok, I'm fine with that | 22:39 |
| davecheney | thumper: is writing documents and hating himself | 22:39 |
| * thumper is looking at docs and trying to stay sane | 22:39 | |
| thumper | heh | 22:39 |
| davecheney | menn0: is blocked on schema upgrades | 22:39 |
| davecheney | and waigani is doing reviews | 22:39 |
| davecheney | ta-da: 15 second standup (tm) | 22:40 |
| waigani | ha | 22:40 |
| menn0 | :) | 22:40 |
| menn0 | davecheney: I'm not actually blocked so much now but yes, am definitely working on schema upgrade related stuff. | 22:41 |
| menn0 | davecheney: what are you doing? | 22:41 |
| menn0 | davecheney: never mind. I just saw. | 22:41 |
| * menn0 needs more coffee | 22:41 | |
| menn0 | or less blood in my coffeestream ... | 22:42 |
| menn0 | davecheney, thumper: I went to this morning's core team meeting. It was good but I can't think of anything that came up that's particularly relevant or that you don't already know. | 22:44 |
| menn0 | davecheney, thumper, waigani: one other thing ... I'll be in Brisbane next week and will be working from there on Tues, Wednesday and Friday. | 23:04 |
| waigani | menn0: nice! | 23:05 |
| waigani | menn0: you could work at wallyworld's ;) | 23:05 |
| menn0 | that was the plan originally and I had that lined up but then he ended up having to go to the sprint in Boston | 23:06 |
| menn0 | I may be catching up with him the following Monday (leaving Brisneyland on the 15th). he gets back that day. I'm going to meet bigjools at any rate. | 23:06 |
| davecheney | menn0: oh, you'll enjoy that | 23:07 |
| davecheney | thumper: menn0 waigani alos, but set of ppc64 bugs is growin | 23:10 |
| davecheney | i have 3 atm | 23:11 |
| davecheney | 1 waiting on the upstream | 23:11 |
| davecheney | 1 waiting on the reporter for more informatoin | 23:11 |
| davecheney | i can't remember the status of the third | 23:11 |
| davecheney | i guess axw and wallyworld are on a plane now ? | 23:45 |
| thumper | well that went on longer than expected | 23:47 |
| davecheney | thumper: wanna stand up | 23:47 |
| davecheney | seeing as you're still standing | 23:47 |
| thumper | davecheney: probably not until saturday | 23:47 |
| thumper | davecheney: standup hangout | 23:47 |
| davecheney | mkay | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
