[00:39] <davecheney> http://juju-ci.vapour.ws:8080/job/github-merge-juju/35/?
[00:39] <davecheney> what the heck happened ?
[00:41] <perrito666> davecheney: well first of all, it would seem that the bot is not properly merging stuff since at some point i in detached mode
[00:41] <davecheney> can anyone just hulk smash this
[00:41] <davecheney> this is blocking a fix
[00:41] <davecheney> i've been trying to merge this SOB for 3 days
[00:43] <perrito666> davecheney: wallyworld_ is the man you are looking for
[00:43] <perrito666> well perhaps its mgz but I hink at thi time you can only get wallyworld_
[00:44]  * wallyworld_ is having network issues :-(
[00:44] <wallyworld_> so i missed the question
[00:44] <davecheney> wallyworld_: can you land https://github.com/juju/juju/pull/10 manually
[00:44] <davecheney> i've been stuck on this for days
[00:44] <wallyworld_> sure, why?
[00:45] <davecheney> http://juju-ci.vapour.ws:8080/job/github-merge-juju/35
[00:46] <wallyworld_> so don't you need to fix the merge conflict first?
[00:46] <davecheney> thanks
[00:46] <davecheney> i'll try again
[00:46] <davecheney> that probably means someone already bumped the versino of juju testing
[00:46] <davecheney> so I probablky don't need to do this at all
[00:47] <wallyworld_> i am happy to help if needed
[00:49] <davecheney> wallyworld_: thanks for your help, I think I have it now
[00:49] <wallyworld_> ok, i didn't do anything though :-)
[00:50] <perrito666> wallyworld_: your sole presence is enough
[00:51] <wallyworld_> debatable :-)
[01:05] <davecheney> hey, what's happening with juju/names ?
[01:07] <davecheney> looks like the job is 1/2 done
[01:07] <jcw4> davecheney: how so?
[01:07] <davecheney> is there a job to nuke the copy in juju/juju ?
[01:07] <davecheney> + ./bin/lander-merge-result --ini development.ini --pr=10 --job-name=github-merge-juju --build-number=36
[01:07] <davecheney> Failed to add comment: Failed to merge: {u'sha': u'6bbbdb86e38120549487326600e16bc1a340d59d', u'message': u'Pull Request successfully merged', u'merged': True}
[01:07] <davecheney> ++ date
[01:07] <davecheney> + echo Finished: Fri Jun 6 01:07:08 UTC 2014
[01:07] <davecheney> Finished: Fri Jun 6 01:07:08 UTC 2014
[01:07] <davecheney> + exit 0
[01:08] <davecheney> Description set: davecheney 101-update-juju-testing-dependency
[01:08] <davecheney> Finished: SUCCESS
[01:08] <davecheney> wallyworld_: failed, but success ?
[01:09] <wallyworld_> otp, sec
[01:10] <jcw4> davecheney: sorry, I thought you were talking about in your own repo/branch
[01:10] <jcw4> :)
[01:13] <wallyworld_> davecheney: yeah, dumb message, github seems to think it's merged from what i can see. i'll get martin to look into it as he's tidying up all that stuff at the moment
[01:14] <davecheney> wallyworld_: i'm moving on to finishing the juju/names package
[01:14] <davecheney> that is blocking me today
[01:15] <wallyworld_> davecheney: ok, but at least your dep change got merged even if the console message sucked
[01:15] <davecheney> \o/
[01:15] <davecheney> i'll go close the bug on LP then
[01:52] <wallyworld_> axw: so i have a large set of changes i want to split up into 2 branches (like a bzr pipeline). i want to add a pre-req branch to my current one. the work is currently not committed. do you know how to do that efficiently with git? do a need that stacked git addon?
[01:54] <axw> wallyworld_: why do you want to do it in two branches - just to split up the review?
[01:54] <wallyworld_> yeah
[01:54] <wallyworld_> like we do in launchpad and bzr
[01:55] <wallyworld_> and i want to switch between the 2
[01:55] <wallyworld_> make changes in the upstream one and push those to the other
[01:55] <axw> so there's no prereq sort of thing in GH. if they're small enough, you could just put them in one review as separate commits. you can then see commit-specific changes in the review
[01:56] <axw> I don't know much about stacked git, just that it exists
[01:56] <wallyworld_> ok, ta
[01:56] <wallyworld_> i'm really missing bzr and launchpad already
[01:59] <davecheney> https://github.com/juju/juju/pull/34
[01:59] <davecheney> ^ finishes the move to juju/names
[02:00] <thumper> davecheney: https://github.com/juju/juju/pull/27
[02:01] <davecheney> thumper: I don't get it
[02:01] <davecheney> my working copy doesn't have this
[02:01] <davecheney> oh fuck
[02:01] <thumper> git fetch upstream?
[02:01] <davecheney> how do you set that up ?
[02:01] <thumper> davecheney: what do you have now?
[02:02] <davecheney> just editied .git/config to set original to my fork
[02:02] <davecheney> thats it
[02:02] <thumper> git remote -v
[02:02] <davecheney> lucky(~/src/github.com/juju/juju) % git remote -v
[02:02] <davecheney> origin	https://github.com/davecheney/juju (fetch)
[02:02] <davecheney> origin	https://github.com/davecheney/juju (push)
[02:02] <thumper> ok...
[02:02] <axw> git remote add upstream https://github.com/juju/juju.git
[02:02] <wallyworld_> davecheney: were there supposed to be so many changes to dependencies.tsv in you mp?
[02:03] <davecheney> wallyworld_: supposed to only be one change
[02:03] <thumper> davecheney: git remote set-url origin git@github.com:davecheney/juju.git
[02:03] <wallyworld_> the diff has a few more than that
[02:03] <davecheney> i do godeps -t $SOMEPKG >> dependencies.tsv
[02:03] <thumper> davecheney: and what axw said
[02:03] <thumper> then do:
[02:03] <davecheney> then hand edit dependencies.tsv afterwards
[02:03] <davecheney> because godeps is so pickup about the file format
[02:03] <wallyworld_> i just always hand edit it
[02:03] <thumper> git branch --set-upstream-to remotes/upstream/master
[02:04] <davecheney> % git branch --set-upstream-to remotes/upstream/master
[02:04] <davecheney> error: the requested upstream branch 'remotes/upstream/master' does not exist
[02:04] <thumper> but  do "git fetch upstream " first
[02:04] <thumper> sorry
[02:04] <thumper> ordering
[02:04] <davecheney> ok
[02:04] <thumper> davecheney: also "git remote set-url --push upstream no-pushing" will mean you can't accidentally push upstream
[02:05] <wallyworld_> davecheney: so i think you need to fix the tsv file so the diff only shows one change
[02:05] <davecheney> there is no way i'll remember this
[02:05] <axw> if anyone cares, I have a local branch called "master" that tracks upstream/master. I pull into this and branch off there for my feature branches
[02:05] <davecheney> is this writtne down anywhere
[02:05] <thumper> davecheney: you only have to do it once
[02:05] <thumper> and I think it is written down
[02:05] <thumper> if not, it should be
[02:06] <wallyworld_> wtf is git so obtuse and difficult?
[02:11] <davecheney> thumper: do I need to do the updates upstream thing for every juju repo ?
[02:12] <thumper> yes
[02:12] <davecheney> ok
[03:28] <jcw4> menn0: great feedback so far... let me know when you're done and I'll respond to them all
[03:30] <menn0> jcw4: will do
[03:44] <sinzui> CI Loves trunk after 9 days. Blessed: gitbranch:master:github.com/juju/juju 6bbbdb86 (Build #1451)
[03:45] <jcw4> sinzui: yay
[03:51] <waigani> thumper: https://github.com/juju/juju/pull/35
[03:53] <waigani> axw: I have the same setup
[04:04] <waigani> thumper: you about?
[04:09] <menn0> jcw4: all done
[04:09] <jcw4> menn0: sweet, all good comments thanks
[04:09] <menn0> jcw4: sorry that I don't feel like I can LGTM it (due to my lack of background, not a problem with the code)
[04:10] <jcw4> I'll address the stuff you brought up and then ask fwereade for review too..
[04:10] <menn0> cool
[04:10] <jcw4> menn0: no worries, I appreciated all your feedback
[04:10] <menn0> hopefully I've caught a few things fwereade would have otherwise
[04:12] <menn0> davecheney: regarding  https://github.com/juju/juju/pull/34
[04:13] <menn0> davecheney: I've seen your comment. Is the diff shown no longer accurate?
[04:14] <davecheney> menn0: it is accurate
[04:14] <menn0> davecheney: ok, the comment confused me a little. I will review!
[04:15] <axw> if anyone's able to review goose changes, I need one please: https://codereview.appspot.com/103900045
[04:16] <menn0> davecheney: why the changes of errors.New to fmt.Errorf?
[04:16] <davecheney> menn0: why have two differnt ways of making an error ?
[04:17] <menn0> davecheney: ok. so because fmt.Errorf is more flexible you're standardising to that?
[04:18] <davecheney> just reducing the number of imports
[04:18] <davecheney> why import errors to make one call to it
[04:18] <davecheney> when fmt is already imported and does the smae job
[04:18] <menn0> why not use the new juju/errors package which gives tracing?
[04:19] <menn0> davecheney: ^^
[04:19] <davecheney> menn0: it was just a cleanup
[04:19] <davecheney> i'm not trying to boil the ocean
[04:19] <menn0> davecheney: fair enough. but in general we should be using juju/errors right? esp for new stuff?
[04:19] <davecheney> menn0: nfi
[04:20] <menn0> davecheney: I think we are but that doesn't matter for this change ;-)
[04:20] <davecheney> afaik the errors package is for wrapping other errors
[04:21] <menn0> davecheney: it also generates new errors with the source information recorded
[04:21] <menn0> there's New and Errorf which are compatible with the standard library functions
[04:23] <menn0> davecheney: anyway, review done.
[04:23] <davecheney> ta
[04:35] <thumper> waigani: here now
[04:35] <thumper> and missed the ping from before
[04:35] <thumper> was collecting daughter
[05:12] <waigani> davecheney: creating a test for the error, I can't see how to do this. d.dir is not exported, so I can't override that ... ?
[05:15] <waigani> menn0: thumper: github is erasing my backslashes. The regex in the comment *should* read: ^.+\.jenv$
[05:17] <menn0> waigani: regardless I still think you should consider using Glob instead of a regex :)
[05:17] <waigani> menn0, thumper: what are we doing for review fixes? amending? rebasing? or just pushing?
[05:19] <menn0> waigani: I've generally been editing history (either git commit --amend or some kind of rebase) and pushing with --force. Github handles that pretty well and it's not like anyone is going to be checking out your PR on their machine.
[05:19] <waigani> menn0: Cool I'll amend and push -f
[05:19] <menn0> waigani: if there was a large change in response to a review comment then I would probably commit it was a separate rev
[05:20] <waigani> yeah, fair enough, makes sense
[05:28] <jcw4> menn0: I'm going to run some smoke tests on my changes and push an update to PR https://github.com/juju/juju/pull/33
[05:28] <jcw4> menn0: I did make one comment and asked one question in there though
[05:28] <menn0> jcw4: cool. I'm about to finish up but can hang around for a little longer
[05:33] <jcw4> no worries menn0 I'm eod'ing right after I push...
[05:37] <menn0> jcw4: I've responded to your comments. I thought of more potential issues with the ActionResults() lookup unfortunately.
[05:38] <jcw4> heh... thanks menn0
[05:40] <jcw4> menn0: how about ActionResultsForUnit(globalKey), and ActionResultsForAction(actionId)?
[05:40] <menn0> jcw4: yes, that sounds good
[05:40] <jcw4> cool, tx
[05:42] <menn0> jcw4: another thought: a comment describing the structure the of the action ids might be useful
[05:42] <jcw4> menn0: +1
[05:42] <menn0> right I'm done
[05:43] <jcw4> ta
[05:43]  * menn0 thinks review duty is hard work (but rewarding)
[05:44] <menn0> have a good weekend all
[06:14] <jcw4> Okay I pushed latest changes for PR https://github.com/juju/juju/pull/33
[06:16] <jcw4> fwereade: if you get a chance today your input would be appreciated
[06:25] <wallyworld_> axw: i'm getting errors trying to push a feature branch (missing packages). so i changed to master, did a git pull upstream master. i want to push that to my fork on gh using git push origin but still it says  packages are missing. do you know what i need to do?
[06:26] <axw> wallyworld_: sounds like the pre-push hook is failing
[06:26] <axw> wallyworld_: some packages have been moved around (out of juju/juju)
[06:26] <axw> you probably just need to go get them
[06:27] <wallyworld_> ok, will try. git is so easy to use
[06:42] <axw> wallyworld_: sorted?
[06:44] <wallyworld_> no :-( sort of. i was working on branch A. I committed some files. I stahsed the rest. I checkout -b branch B. I pop the stash. I commit and push. Now branch B in the pull request has all the stuff from branch A as well
[06:44] <wallyworld_> and I can't do anything with branch B because it depends on changes in branch A
[06:44] <wallyworld_> this sucks
[06:46] <wallyworld_> so ideally i want to delete stuff from branch B (all of the branch A work)
[06:47] <wallyworld_> but nothing in the log seems to indicate where the branch A stuff came from to get into branch B
[06:56] <dimitern> fwereade, jam, please take a last look at https://github.com/juju/juju/pull/13 i really need an approval to land it already
[07:02] <axw> wallyworld_: if you "checkout -b", that's coming off the branch you were previously on
[07:02] <axw> wallyworld_: if you didn't want the stuff from A, branch off master
[07:03] <axw> wallyworld_: now that you've done that, you can just "git rebase -i master" and delete the commits you don't want in that branch
[07:08] <wallyworld_> axw: thank, will do that after soccer
[07:26] <rogpeppe1> does anyone know if the issues with the jenkins bot are fixed yet?
[07:26] <rogpeppe1> axw: ^
[07:27] <axw> rogpeppe1: issues?
[07:28] <rogpeppe1> axw: there was a checksum issue which was causing all builds to fail like this http://juju-ci.vapour.ws:8080/job/github-merge-juju/30/consoleText
[07:28] <rogpeppe1> axw: because the go tool wasn't available
[07:28] <rogpeppe1> axw: if you've succeeded in landing stuff, i guess it's fixed
[07:29] <axw> rogpeppe1: I'm pretty sure I've seen things landed today
[07:29] <rogpeppe1> axw: ok, i'll try again
[07:32] <BjornT> could someone please take a quick look at this bug and say what more information i can add to it, before i shutdown the failed instance?  https://bugs.launchpad.net/juju-core/+bug/1327078
[07:32] <_mup_> Bug #1327078: Failed to bring up an LXC with 1.19.3 <landscape> <juju-core:New> <https://launchpad.net/bugs/1327078>
[07:46] <rogpeppe1> anyone know what happened to lbox.check? i'd like to run the checks locally that the bot runs remotely, so i don't do silly things like forget to gofmt or govet.
[07:47] <rogpeppe1> (having just realised i failed to gofmt my last merge req)
[07:47] <axw> BjornT: if there's no /var/lib/juju, then I think cloud-init-output is all we can work with
[07:47] <axw> rogpeppe1: symlink scripts/pre-push.bash as .git/hooks/pre-push
[07:47] <BjornT> axw: ok, thanks
[07:48] <rogpeppe1> axw: ah, excellent, thanks - i'd have taken ages to find that
[07:48] <axw> np
[07:49] <rogpeppe1> axw: is the pre-push script guaranteed to run in the root dir of the repo>
[07:49] <rogpeppe1> ?
[07:49] <rogpeppe1> axw: (when doing git push)
[07:49] <axw> sinzui: interesting thing I found - the HA-failing-on-precise thing only occurs on your machine when the mongo db is on the ephemeral disk
[07:49] <axw> rogpeppe1: yes, I confirmed that
[07:50] <axw> pushed from some other subdir, it always was run in the root
[07:51] <rogpeppe1> hmm, pity it takes 30s to run
[07:54] <rogpeppe1> cp /bin/true $(go tool -n vet)
[08:07] <voidspace> morning all
[08:12] <TheMue> morning
[08:16] <dimitern> TheMue, hey
[08:17] <dimitern> TheMue, I need an LGTM on this if you can take a look - I fixed all that was suggested earlier https://github.com/juju/juju/pull/13
[08:19] <TheMue> dimitern: yep, will take a look
[08:19] <axw> voidspace: I've had a breakthrough on the local-provider/replicaset issue
[08:19] <dimitern> TheMue, thanks
[08:19] <axw> voidspace: I can reproduce it on my own m2.xlarge instance
[08:19] <axw> voidspace: the trick is to use the ephemeral disk as the root-dir
[08:19] <axw> if you use the EBS disk it works fine
[08:30] <rogpeppe1> is there any way of telling jenkins to stop retrying tests because i've pushed a new version of the branch?
[08:32] <voidspace> axw: ah right
[08:32] <voidspace> axw: interesting
[08:40] <TheMue> dimitern: a bit hard to follow now on GH. the comment by william yesterday at 10:16 (at the bottom), is it covered?
[08:44] <dimitern> TheMue, about constraints?
[08:44] <dimitern> TheMue, yes
[08:44] <dimitern> TheMue, there are a few things i'll do in follow-ups as agreed as well
[08:44] <TheMue> dimitern: fine
[08:45] <TheMue> dimitern: done
[08:45] <dimitern> TheMue, cheers
[08:45] <TheMue> dimitern: does GH provide a side-by-side diff too?
[08:46] <dimitern> TheMue, no, but menno found some chrome extension that gives you that - check the mailing list
[08:53] <TheMue> dimitern: chrome is a no-go for me, it’s a resource hog. since changing to ff everything runs better, even the google apps like mail or hangout
[08:56] <voidspace> axw: any idea *why* that should make a difference - IO performance?
[08:57] <axw> voidspace: not really. I wouldn't think it'dbe iops, because the ephemeral disk should be faster
[08:57]  * axw checks hdparm
[08:58] <rogpeppe1> ffs, it's *still* retrying the tests
[08:58] <voidspace> axw: can you reproduce it with trusty?
[08:58] <voidspace> axw: or is it just precise
[08:58] <axw> voidspace: I did, same issue. I sent instructions to juju-dev on how to repro
[08:58] <voidspace> axw: ah yes, I see
[08:58] <axw> voidspace: EBS on that machine gets 80.33MB/s, ephemeral gets 552.59MB/s
[08:59] <axw> voidspace: I tried it on m3.xlarge and the ephemral disk was fine. on there it's an SSD though
[09:00] <rogpeppe1> it seems like a failed test delays the merge queue by at least 30 minutes. that's really not great.
[09:00] <axw> rogpeppe1: we are working on improving it, there are still some intermittent failures
[09:01] <rogpeppe1> axw: it would be great if it was possible to tell jenkins "please kill this job now - i know it's going to fail"
[09:01] <axw> hmm yes, that would be nice...
[09:04] <rogpeppe1> axw: even with intermittent failures, it might still be better if it didn't retry automatically
[09:04] <rogpeppe1> axw: then at least the person responsible can look at the failure and see if it looks like it's correctly intermittent, or if it's just a bad test
[09:05] <axw> initially it was so bad that we had to, but now, yeah, I think you may be right
[09:07] <rogpeppe1> right, hoping for 5th time lucky
[09:09] <rogpeppe1> dimitern: your branch failed to merge: tmp.ZRpISWCH5X/RELEASE/src/github.com/juju/juju/juju/testing/instance.go:119: undefined: includeNetworks
[09:10] <rogpeppe1> dimitern: (i can't say i'm unhappy because if yours had succeeded, mine would probably have failed. again)
[09:10] <dimitern> rogpeppe1, yep, some merge didn't go well i'm fixing it
[09:11] <voidspace> axw: hmmm... maybe my Friday project can be to diagnose this
[09:11] <axw> heh :)
[09:12] <axw> well it sure is mystefying, so it's gotta be educational if you can figure it out
[09:12] <voidspace> right
[09:12] <voidspace> not useful education, but education none-the-less ;-)
[09:36] <rogpeppe1> i love my ISP
[09:36] <rogpeppe1> ssh: Could not resolve hostname github.com: Name or service not known
[10:01] <voidspace> rogpeppe1: stop using their dns?
[10:02] <rogpeppe1> voidspace: i think it's just the whole thing's flaky. i get random delays, even when i'm not using their dns
[10:34] <rogpeppe1> dimitern: provider/ec2/local_test.go:359: too many arguments in call to "github.com/juju/juju/juju/testing".StartInstanceWithParams
[10:34] <dimitern> rogpeppe1, just fixed that, but I can't stop the ci job
[10:34] <rogpeppe1> mgz: would it be possible to turn off the automatic test retry on the bot?
[10:34] <rogpeppe1> mgz: it's taking over an hour to process a commit with a test failure
[10:36] <mgz> rogpeppe1: maybe
[10:36] <mgz> I ill at least cut down to two I think
[10:37] <mgz> we have still got bogus failures
[10:37] <rogpeppe1> mgz: i think one would be better
[10:37] <rogpeppe1> mgz: we've got to look at the failure status anyway
[10:38] <rogpeppe1> mgz: and it takes 18 minutes to process a job if all goes well
[10:38] <rogpeppe1> mgz: but doubling that when a test fails seems wrong
[10:38] <mgz> I prefer to inconvience on failing test run, rather than on good branhc that hits a random issue
[10:39] <rogpeppe1> mgz: it inconveniences everyone though
[10:39] <rogpeppe1> mgz: i've spent the entire morning waiting for the bot
[10:40] <rogpeppe1> mgz: can we *try* not retrying
[10:40] <rogpeppe1> ?
[10:40] <rogpeppe1> mgz: and if the sporadic failures turn out to be a real problem, going back to retrying
[10:41] <rogpeppe1> mgz: alternatively, try to diagnose the sporadic failures and only retry if it looks like one of those
[10:41] <dimitern> and I can't merge my PR for 2 days because everything keeps changing across the codebase - imports mostly
[10:41] <rogpeppe1> dimitern: yeah, sorry about that
[10:41] <rogpeppe1> dimitern: nothing i can do to help about that, but it does mean that we *can't* submit PRs that will definitely work
[10:42] <rogpeppe1> dimitern: because we have fundamentally clashing branches
[10:42] <mgz> rogpeppe1: we've already had runs that have only landed successfully because of the retry
[10:42] <mgz> see build 34 for instance
[10:43] <rogpeppe1> mgz: any other examples?
[10:43] <mgz> I'mm trying to find the graph thingy
[10:44] <dimitern> mgz, we need accounts on the jenkins ci instance for cases like this - stopping a build that'll never succeed
[10:44] <mgz> dimitern: we don't really
[10:44] <mgz> we just need our tests to not be so flakey
[10:44] <mgz> then 10-15mins for a run is fine
[10:44] <dimitern> and the retry logic can detect build failures and do not attempt to retry
[10:46] <mgz> juju-ci.vapour.ws:8080/job/github-merge-juju/buildTimeTrend
[10:46] <mgz> I've changed the job to do a single retry, it should fail in around 30-35 mins now
[10:46] <dimitern> haha :) beat you to it rogpeppe1  :)
[10:46] <dimitern> sorry about that
[10:46] <rogpeppe1> dimitern: frick
[10:47] <mgz> #36 #23 #21 all required the rerun
[10:47] <rogpeppe1> mgz: could we please change it to no retries at least for today
[10:47] <rogpeppe1> ?
[10:48] <rogpeppe1> mgz: because dimitern and i are conflicting and we're constantly watching the jobs and a failing job can double the time we're going to need for all this overhead
[10:48] <mgz> rogpeppe1: I feel you two could work out a better solution between yourselves..
[10:49] <mgz> but okay, I'll put it back in after y'all have sorted out your mess
[10:49] <perrito666> good morning everyone
[10:50] <rogpeppe1> mgz: so, all those intermittent failures failed with "panic: Session already closed"
[10:50] <dimitern> rogpeppe1, I think changes like this (extracting a dependency and changing all imports) is very frustrating to deal with, especially when they are several like that in a row
[10:50] <rogpeppe1> mgz: wouldn't it be possible to see that and retry only in that case?
[10:50] <rogpeppe1> dimitern: yeah, particularly when the dependency is widely used
[10:50] <rogpeppe1> perrito666: hiya
[10:51] <voidspace> crazy internet today :-/
[10:51] <mgz> yeay rural england?
[10:51] <voidspace> mgz: yeah, and yay talktalk
[10:51] <dimitern> rogpeppe1, we should've handled that better - announce it on the ML, perhaps pick a day to do a few of these in sequence, so it can be expected and we can fix our PRs after that
[10:52] <voidspace> rogpeppe1: got a minute to help me diagnose a problem?
[10:52] <rogpeppe1> voidspace: sure
[10:52] <rogpeppe1> voidspace: yay talktalk :-\
[10:52] <voidspace> yeah
[10:52] <TheMue> dimitern: missed our hangout, but now nobady is there. has it already been?
[10:52] <rogpeppe1> voidspace: my talktalk connection is really crappy today too
[10:53] <rogpeppe1> voidspace: do you have slow/crappy DNS issues too?
[10:53] <voidspace> rogpeppe1: heh, maybe coincidence maybe not
[10:53] <voidspace> rogpeppe1: I don't use their DNS
[10:53] <rogpeppe1> voidspace: 8.8.8.8 ?
[10:53] <dimitern> TheMue, i haven't bothered today :) my bad - we can still do it, though if we need
[10:53] <voidspace> rogpeppe1: this test passes
[10:53] <voidspace> http://pastebin.ubuntu.com/7601025/
[10:53] <voidspace> rogpeppe1: but note the 20 second sleep
[10:53]  * dimitern is not ipv6 capable :)
[10:53] <voidspace> without that it fails
[10:54] <TheMue> dimitern: I’ve got nothing special, so it’s ok for me to not do it
[10:54] <TheMue> ;)
[10:54] <dimitern> my shiny new hurricane electric tunnel just works
[10:54] <dimitern> (after a few issues resolved)
[10:54] <voidspace> rogpeppe1: without it state.Open fails with
[10:54] <voidspace> ... value *errors.errorString = &errors.errorString{s:"no reachable servers"} ("no reachable servers")
[10:54] <voidspace> rogpeppe1: so I need some way of polling for when mongo is ready
[10:55] <voidspace> I suspect it is waiting for replica set initiation
[10:55] <dimitern> who's most git-savvy around?
[10:55] <rogpeppe1> voidspace: does it work if you increate the DialOpts timeout to 30s from 10?
[10:55] <rogpeppe1> dimitern: me! *chortle*
[10:55] <voidspace> rogpeppe1: ah...
[10:55] <dimitern> i have this issue almost every time i need to push changes from a PR branch after fixing stuff/review comments
[10:56] <dimitern> it tells me Updates were rejected because the tip of your current branch is behind
[10:56] <voidspace> rogpeppe1: it's set to testing.LongWait
[10:56] <dimitern> how can my local branch be behind my origin/samebranch ?
[10:56] <voidspace> rogpeppe1: which is ten seconds
[10:56] <rogpeppe1> voidspace: exactly
[10:56] <voidspace> rogpeppe1: should I create a VeryLongWait ?
[10:56] <voidspace> or hard code 30 seconds?
[10:56] <rogpeppe1> voidspace: just hardcode it
[10:56] <voidspace> ok
[10:56] <dimitern> what do you guys use as a workflow? we need to document it somewhere more extensively
[10:57] <rogpeppe1> voidspace: is that git complaining?
[10:57] <rogpeppe1> voidspace: when you try to do the push?
[10:57] <rogpeppe1> oops
[10:57] <rogpeppe1> dimitern: ^
[10:57] <dimitern> (i.e. more than what you do initially, but also how you do specific steps)
[10:57] <dimitern> rogpeppe1, yep
[10:57] <rogpeppe1> dimitern: are you rebasing before pushing?
[10:57] <dimitern> rogpeppe1, the only way i found around it is push -f
[10:58] <dimitern> rogpeppe1, sometimes, but not always
[10:58] <rogpeppe1> dimitern: if you rebase, you'll have that problem
[10:58] <voidspace> rogpeppe1: that passes
[10:58] <voidspace> ship it!
[10:58] <voidspace> rogpeppe1: thanks
[10:58] <rogpeppe1> dimitern: if you don't, you should not
[10:58] <rogpeppe1> dimitern: i've stopped doing any rebasing
[10:58] <rogpeppe1> dimitern: after the discussion on juju-dev
[10:59] <dimitern> rogpeppe1, without rebasing you get a lot of pollution in the commit log
[10:59] <rogpeppe1> dimitern: if you're going to rebase, then do it a) before starting the review and/or b) just before sending the $$merge$$ message
[10:59] <dimitern> rogpeppe1, like your PR might land from a branch which last commit was "Fixed merge conflicts", which you'll see in the upstream master commit log, rather than your nicely formatted commit message
[10:59] <rogpeppe1> dimitern: but i think i'd go with just the former
[11:00] <rogpeppe1> dimitern: yup
[11:00] <rogpeppe1> dimitern: this is the world we've moved into
[11:00] <dimitern> rogpeppe1, i really don't like that
[11:00] <rogpeppe1> dimitern: if you rebase you'll have to push -f
[11:00] <rogpeppe1> dimitern: because push will only step forward in time
[11:01] <voidspace> rogpeppe1: I already had an LGTM, the only change I've made since is increased that timeout
[11:01] <dimitern> rogpeppe1, there has to be a better way to have both sane commit logs eventually and the ability to go over a reviewed branch fixing stuff
[11:01] <voidspace> rogpeppe1: so I'm going to merge, unless you want to take a look first...
[11:01] <rogpeppe1> dimitern: rebase just before sending the $$merge$$ message
[11:01] <rogpeppe1> voidspace: sgtm
[11:01] <voidspace> rogpeppe1: thanks
[11:02] <rogpeppe1> dimitern: but as discussed on juju-dev, you can still see sane commit logs even when all commits go in
[11:02] <rogpeppe1> dimitern: and i'd prefer not to all the extra overhead of rebasing
[11:02] <rogpeppe1> s/not to/not to add/
[11:02] <natefinch> I think it's worth not rebasing if we still have a way to see sane logs of all the merges going in
[11:02] <rogpeppe1> natefinch: +1
[11:03] <dimitern> rogpeppe1, how's that going to work?
[11:03] <voidspace> natefinch: morning
[11:03] <voidspace> fwereade: ping
[11:03] <natefinch> voidspace: morning
[11:03] <dimitern> rogpeppe1, examples?
[11:03] <fwereade> voidspace, pong
[11:03] <rogpeppe1> dimitern: see the juju-dev thread
[11:03] <natefinch> dimitern: called not rebasing after PR
[11:04] <dimitern> rogpeppe1, natefinch, will do, thanks
[11:18] <rogpeppe1> can anyone thing of a particular reason why juju/testing/charm.go should not live inside charm/testing ?
[11:18] <rogpeppe1> s/thing/think/
[11:20] <rogpeppe1> it doesn't seem like it should live in github.com/juju/testing, to my mind
[11:20] <rogpeppe1> although... i suppose we could move charm/testing into github.com/juju/testing/charmtesting
[11:20] <rogpeppe1> jam, jam1: ^
[11:27] <bodie_> morning all
[11:35] <mgz> morning bodie_
[11:39] <natefinch> rogpeppe1: seems like charm.go should be in charm/testing   seems like a good idea to keep charm stuff away from the rest of core
[11:39] <rogpeppe1> natefinch: that's my thought too
[11:48] <perrito666> voidspace: did you see axw mail about the replicaset enabled for local issue, apparently he found out what it was, or at least very close
[11:52] <voidspace> perrito666: I did see
[11:52] <voidspace> perrito666: he found a way to reproduce it
[11:52] <voidspace> perrito666: which is not quite the same as finding out what it is :-)
[11:52] <voidspace> being able to reproduce it is useful
[11:52] <voidspace> I might do some experimentation
[11:53] <perrito666> well he mentioned having an idea of what it is :) he just did not tell us
[11:54] <mgz> he knows how to reproduce it, not fix it. he wasn't leaving it as an educational puzzle for you guys :)
[11:59] <perrito666> mgz: oh, sad, I love puzzles
[12:00] <perrito666> although, technically if we don't use ephemeral storage, it would be "fixed" :p or at least workarounded
[12:01] <perrito666> anyone else with good grammar and redaction skills wants to take a shot at https://github.com/juju/juju/pull/30 ?
[12:01] <perrito666> rogpeppe1 and menn0 have both added very valuable comments which where addressed but being docs, the more the merrier
[12:01]  * mgz redacts perrito666
[12:02]  * rogpeppe1 wonders what is different in the ephemeral fs semantics
[12:03]  * perrito666 wonders if redacting means the same in English than in Spanish
[12:06] <mgz> perrito666: I suspect not, but *common* usage in english is now as in "draw black lines over sensitive parts" rather than editing in general
[12:07] <mgz> so, it's generally understood as closer to "censor" than "edit"
[12:07] <perrito666> mgz: ahh, I see, in Spanish is used for "create a text" or "properly format a text"
[12:08] <mgz> yeah, that's pretty much the orignal english meaning
[12:08]  * perrito666 has an outdated dictionary
[12:09] <natefinch> there's the definition, and then what people *mean* - often different
[12:10] <perrito666> meh, users :p
[13:46] <voidspace> the build for my branch passed: http://juju-ci.vapour.ws:8080/job/github-merge-juju/?
[13:46] <voidspace> (build 47)
[13:46] <voidspace> but it still hasn't merged yet
[13:46] <voidspace> this was a few hours ago
[13:58] <mgz> voidspace: looking
[13:58] <mgz> voidspace: see the end of the log
[13:59] <mgz> I'll run the command manually see if it now works
[13:59] <mgz> nope...
[14:01] <mgz> I wonder if our bots merging can pass when github itself will fail, I'm not sure what strategy they use exactly
[14:02] <voidspace> mgz: ah, failed to merge
[14:02] <mgz> voidspace: can you see if you conflict with trunk at all?
[14:02] <voidspace> sure
[14:02] <mgz> I wonder if the preceeding pull conflicts, but when the bot pulled trunk for the next run it didn't get that yet
[14:02] <mgz> or something
[14:03] <natefinch> voidspace, perrito666, wwitzel3: standup
[14:03] <voidspace> mgz: merge seemed to work fine, no conflict
[14:03] <voidspace> pushing
[14:03] <voidspace> natefinch: might just be you and me
[14:06] <mgz> voidspace: also wtf is up with python and getattr({u"a":1}, "a") vs {u"a":1}["a"]
[14:06] <mgz> last successful job also failed my branch to catch this, even though I *did* change it to use the unicode literal
[14:06] <voidspace> mgz: getattr does an attribute lookup
[14:06] <voidspace> mgz: that's an *item lookup*
[14:06] <voidspace> mgz: not an attribute
[14:06] <mgz> doh!
[14:06] <voidspace> mgz: so uhm, they're different
[14:06] <mgz> too much go
[14:07] <voidspace> mgz: itemgetter?
[14:07] <sinzui> mgz, My branch is merged https://code.launchpad.net/~sinzui/juju-ci-tools/local-tarball/+merge/222266
[14:07] <voidspace> mgz: specifically operator.itemgetter
[14:07] <mgz> I just want `"a" in {..}`
[14:07] <abentley> voidspace: How about just {u"a":1}.get("a") ?
[14:08] <mgz> or that
[14:08] <voidspace> heh, or that
[14:08] <voidspace> unless you *want* the KeyError
[14:08] <sinzui> mgz, We can try to simplify git-merge-juju when you are ready
[14:08] <mgz> nah, the else raises anyway
[14:08] <mgz> sinzui: thanks!
[14:13] <mgz> voidspace: I have requueueeeueued
[14:13] <voidspace> mgz: I saw, thanks
[14:19] <mgz> sinzui: in case you missed it in the log earlier, I took out the test retry for now as it was upsetting rog and dimiter's merge conflict landing fun
[14:20] <sinzui> mgz, understood. I had missed that
[14:21] <sinzui> mgz, did you see I had a pastebined link to how I *thought* git-merge-juju would work? I didn't know about the retry change, but run-unit-tests doesn't retry
[14:21] <fwereade> sorry, didn't realise irc was wedged
[14:21] <mgz> no, I missed that, will find
[14:22] <fwereade> voidspace, are you around?
[14:22] <fwereade> wwitzel3, also, please ping me if you have a moment
[14:22] <voidspace> fwereade: I am, but in standup
[14:22] <sinzui> mgz, http://pastebin.ubuntu.com/7597888/
[14:36] <rogpeppe> mgz: ta!
[14:42] <jcw4> natefinch: menn0 reviewed this yesterday, but wanted other eyes on it too, I've addressed all his issues but the one about the errors package, pending discussion: https://github.com/juju/juju/pull/33
[14:43] <jcw4> fwereade: I'd appreciate a quick sanity check review on ^^ too?
[14:50] <natefinch> forgot you can do markdown in comments, that's awesome
[14:53] <natefinch> jcw4: not a huge fan of encoding one id in another one.  Why do we need to do that?  why not just have a separate field for ActionId?
[14:53] <jcw4> natefinch: that was an early suggestion by fwereade
[14:53] <jcw4> natefinch: not that it was intended to be in stone... just for now
[14:54] <jcw4> natefinch: the benefit is facilitating watchers to filter on specific actions based on key
[14:54] <voidspace> natefinch: just grabbing a drink - back shortly
[14:54] <mgz> voidspace: erk, you hit the random failure the retry was in to get around
[14:54] <natefinch> mgz: doh
[14:55] <natefinch> jcw4: not sure I understand how encoding two keys together makes it easier to watch one of those keys :/
[14:55] <jcw4> natefinch: a unit would have a watcher on the actions collection and filter out only actions that have the unit prefix
[14:56] <natefinch> jcw4: .... or filter on the unitId field if one existed instead?
[14:56] <jcw4> natefinch: that was my original design
[14:57]  * natefinch squints at fwereade 
[14:57] <jcw4> natefinch: fwereade wasn't issuing an edict just suggesting we try the simpler approach until clarity emerged
[14:57] <jcw4> :)
[14:57] <jcw4> natefinch: but you're looking at ActionResults, not Actions... I propogated the pattern because it seemed to make sense to keep it consistent
[14:58] <rogpeppe> anyone know of a (nicely implemented) package that implements recursive directory copying?
[14:58] <fwereade> natefinch, there's a quick select-on-initial-simple-regexp which we can use to build the initial watcher cleanly, using just ids without further db hits
[14:58] <jcw4> natefinch: ActionResults don't need a watcher, so a regular key would probably be fine with an ActionId and a Unit Name in it
[14:58] <rogpeppe> i want to change charm/testing so it doesn't use cp -r
[14:59] <fwereade> natefinch, it's how relation scope watching works and it seems like a tolerable approach to me
[15:00] <voidspace> mgz: heh
[15:00] <voidspace> mgz: github hates me
[15:00] <fwereade> jcw4, I'm not sure you're right that the results collection doesn't need a watcher; it *probably* doesn't need a watcher that'd benefit from that id style
[15:00] <jcw4> natefinch: I've also already run into a couple spots where filtering on key seems to be easier than loading the whole doc
[15:00] <voidspace> mgz: in fact git hates me, which is why I never got on with it in my previous attempts
[15:00] <jcw4> fwereade: I see... I haven't been able to think of a watcher for results, but I may not be trying hard enough.
[15:00] <jcw4> :)
[15:01] <fwereade> jcw4, but I'm not sure I'd want to rule it out -- at the very least you'll want to watch for completion of a particular action, and I can imagine that as a gui user you'd probably want to get completed action notifications streamed in along with everything else
[15:01] <jcw4> fwereade: +1
[15:02] <natefinch> fwereade: it just requires that we have intimate knowledge of how the id is constructed.... I've been burned before by code merging two strings and then encoding the knowledge of what the two strings are supposed to be in various places in the code (or even in a single place).
[15:02] <fwereade> jcw4, but given the 1:1 correspondence of actions to results I'm pretty comfortable keeping the keys the same
[15:02] <jcw4> natefinch: agreed, but I've tried to abstract the details away behind funcs as much as possible
[15:02] <voidspace> natefinch: I'd really like to take a break
[15:03] <jcw4> fwereade: could you imagine multiple results for one action?
[15:03] <natefinch> voidspace: what do you need?
[15:03] <fwereade> jcw4, I don't... *think* so
[15:03] <voidspace> natefinch: well, we need to decide what we're doing next (collectively) and which bit I should take on
[15:04] <voidspace> natefinch: I think we've decided we're *not* going to need to stop mongo, so we're not going to need to take down a state server for maintenance
[15:04] <natefinch> fwereade: do you know why we were stopping mongo to run backup before?  Was it just that we didn't know there was a better way?
[15:04] <fwereade> natefinch, I'd suggest most of the problem lies in allowing the knowledge of that string's structure to spread through the codebase instead of properly abstracting it
[15:04] <voidspace> natefinch: we wanted to run by fwereade the idea that instead of a url we have a backup "number" and a "juju fetch-backup n" command
[15:06] <fwereade> natefinch, I forget why we didn't keep mongo going, I'm afraid
[15:07] <natefinch> fwereade: I guess most of my problem with the id thing is that I don't understand why we have to do it.  Why can't you just filter by another field?  You said it causes another db hit, but I don't understand why that is.
[15:07] <fwereade> natefinch, I know it was on the table, but I can't recall if there were complications, or whether the one that got implemented just happened to stop-start and that was acceptable for the use case so we didn't quibble
[15:08] <fwereade> natefinch, primarily because id and txn-revno are the only pieces of information we get out of the watcher package
[15:08] <fwereade> natefinch, we can make useful inferences about watcher events if we encode some meaning in the _id
[15:09] <natefinch> fwereade: I see.
[15:09] <fwereade> natefinch, checking the prefix is what we do when we're filtering the firehose of settings-collection changes to determine which ones apply to a particular watcher
[15:10] <voidspace> natefinch: we shouldn't store any information about available backups in mongo
[15:10] <voidspace> natefinch: we should use the filesystem
[15:10] <fwereade> natefinch, and it seems smart to use the same method of identification where we can, lest subtle semantic drift in other fields catch us unawares
[15:10] <voidspace> natefinch: otherwise restore will think there are backups that don't necessarily exist
[15:10] <fwereade> natefinch, so we also construct initial state with a query for docs with a particular _id prefix
[15:11] <fwereade> natefinch, and it's nice that mongo has a way of doing that query fast
[15:11] <voidspace> natefinch: and restore is interesting - should we allow restoring from a backup already on the state server or should you always have to upload
[15:11] <voidspace> natefinch: if we allow both we need two variants of the restore command
[15:12] <fwereade> natefinch, *also* it's genuinely important that we minimise db hits in our watchers, because any one of them can block the whole watcher infrastructure if it doesn't pick up the events on the channel it registered
[15:16] <fwereade> natefinch, in essence every watcher is implicitly expected to consume every watcher notification fast enough that it's ready and waiting before the next notification comes in; if that's broken, *every* other watcher has to wait for the slow one to catch up
[15:21] <natefinch> fwereade: yeah, I forgot you just watch a collection, and can't pre-filter your watch (like, watch this collection and only show me things that match this query)... and then I also didn't realize all we got out of the notification was the id, not the full document
[15:21] <natefinch> voidspace: that's a good point about restoring from an existing backup on the server already
[15:25] <natefinch> voidspace: yes, we need to keep the backups on disk, not in mongo, so that if everything else on the machine dies, but the disk still works, you can still get your backups.
[15:31] <perrito666> hey, back
[15:31] <perrito666> I notice you are talking about backups
[15:31] <perrito666> my favorite subjects
[15:43] <natefinch> perrito666: are you aware of why we were calling mongodump with --dbpath rather than --oplog?  sounds like --dbpath requires that you stop the db, where --oplog does not
[15:44] <perrito666> natefinch: I became aware last night when I got a mail from fwereade about it
[15:50] <bodie_> https://github.com/juju/juju/pull/42 (mgz)
[15:50] <bodie_> I'll really be happy to get permanently out of charm/actions.go, heh
[15:51] <bodie_> (jcw4, have a look if you like -- this is the simple version of the function to conform keys to strings)
[15:51] <jcw4> bodie_: yeah I'm looking through the diff...
[15:51] <bodie_> mgz, fwereade I wasn't sure if that's too many commits for a single PR, but a few of them were responses to discrete concerns raised over the initial PR, so I figured they might be good to have individually (?)
[15:53] <mgz> bodie, looks much nicer
[16:00] <natefinch> voidspace: ha, Wayne had requested yesterday and today off.  It's in the HR site, just not on the calendar
[16:00] <natefinch> I'd forgotten
[16:01] <perrito666> natefinch: ah, true, he was traveling right?
[16:01] <voidspace> natefinch: ah, cool
[16:01] <voidspace> so he's probably alright then
[16:02] <natefinch> perrito666: yeah, he was working from some other state on Wednesday
[16:11] <natefinch> mgz, fwereade, rogpeppe: anyone want to give me a crash course in writing an API facade?  I can deduce a bunch of the proper structure from the code, but getting some background would help I think
[16:15] <fwereade> natefinch, I might be able to a bit later today, how long are you around for?
[16:16] <natefinch> fwereade: probably later than you, I would think ;)
[16:17] <fwereade> natefinch, yeah, but cath's going out soon -- laura will likely fall asleep before she gets back but the precise time that happens can vary
[16:17] <natefinch> fwereade: I'll stay available
[16:22] <natefinch> brb, grabbing lunch real quick
[16:44] <natefinch> voidspace, perrito666:  so, I think we can split up the work so one person works on writing backup, one person works on writing restore, one person works on writing the code to  list & download the backups
[16:44] <natefinch> and wayne gets whatever crap jobs are left over because he's out today
[16:44] <voidspace> natefinch: sounds good
[16:44] <voidspace> natefinch: I'm about EOD though
[16:44] <voidspace> natefinch: I'm happy for you to assing me stuff to start working on though
[16:45] <natefinch> voidspace: yep, no problem.  I'll get the facade written today so there's a place to put the code monday morning
[16:45] <voidspace> awesome
[16:45] <mgz> rogpeppe: your charm/testing branch may now conflict with trunk, watch out for that when landing
[16:46] <mgz> voidspace: I'd not be happy if he was assing me stuff...
[16:47] <natefinch> mgz: you get used to it after a while
[16:47] <voidspace> hah
[16:47] <voidspace> assign
[16:48] <voidspace> no assing please
[16:48] <natefinch> dang
[16:48] <mgz> ehehe
[17:08] <voidspace> g'night all
[17:57] <jcw4> natefinch: Are you comfortable LGTM'ing this or should I get fwereade to finalize? https://github.com/juju/juju/pull/33
[17:59] <natefinch> jcw4: not sure I understand enough of the background to LGTM it.  You'd just have me asking a bunch of stupid questions, like why we're munging two Ids together ;)
[18:03] <jcw4> natefinch: lol... that was good (and the discussion should be captured in documentation somewhere)
[18:03] <jcw4> natefinch: I'll bug fwereade
[18:03]  * perrito666 hacks juju-backup a lot
[18:06] <natefinch> perrito666: go go go! :)
[18:07] <perrito666> no, actually bash :p
[18:07] <perrito666> well mongodump "works" now let me try to make the same with mongoexport
[18:07] <perrito666> and then lets see if all of that restores
[18:13] <natefinch> perrito666: this says that you restore with mongorestore --oplogReplay: http://docs.mongodb.org/manual/reference/program/mongodump/#cmdoption--oplog
[18:18] <perrito666> natefinch: yup, I am trying to make export work right now
[18:40]  * perrito666 was an hour trying to make mongoexport work only to realize its output is not used to restore
[18:43] <natefinch> heh oops
[18:46] <natefinch> ug... talking to insurance about what is covered and what's not covered.... my favorite thing ever
[18:47] <jcw4> :(
[18:47] <jcw4> hopefully not because of a loss that actually occurred?
[18:48] <perrito666> natefinch: usually whatever happened to you is not covered
[18:53] <natefinch> perrito666: yep
[18:54] <perrito666> did you have an accident?
[18:57] <natefinch> perrito666: nah, just some tests we'd like to do... you know, to make sure things are ok, and if they're not, do something about it before it gets to be a big expensive problem.
[18:58]  * perrito666 thinks ensurance is something different in the US
[18:58] <jcw4> perrito666: I think natefinch is talking about medical insurance
[18:58] <jcw4> which, yes, is something different all right in the US
[19:01] <natefinch> heh yeah
[19:01] <perrito666> ah yes, we have public healthcare or private healthcare which are pretty much the same excepting a few differences on the prettiness of the hospitals
[19:02] <natefinch> it's funny how insurance companies will refuse to pay for the $300 test, but then have to pay for the $10,000 medical procedure the test would have prevented
[19:02] <perrito666> natefinch: wow that is some interesting sum of money, there is no procedure in this country that costs that much
[19:03] <jcw4> perrito666: our insurance system drives the prices way up for many things
[19:03] <natefinch> perrito666: the US is the king of expensive procedures. There's few procedures that are *less* than that, if they involve being in a hospital (versus a doctor's office).
[19:05] <natefinch> yeah, the problem is that hospitals and doctor's practices are generally for-profit corporations, so their motivation is to make a lot of money, which means charging as much as they can get away with, and *doing* as much as they can get away with.  And since a lot of people get insurance through their work, where it's often partially paid for by work, and taken out of their paycheck before they see it.... the average consu
[19:05] <natefinch> mer doesn't really see the cost of the procedures directly... unless you have no insurance, in which case you just go bankrupt any time anything bad happens.
[19:07] <perrito666> wow, but just for you to use as a comparator 10k USD is around 12 times the avg salary in this country so if procedures where that expensive everyone would be dead
[19:07] <jcw4> perrito666: which country are you in?
[19:07] <perrito666> Argentina
[19:08] <natefinch> perrito666: it's 1/5th the median salary here... so, still sort of amazingly expensive.
[19:08] <jcw4> I see, and you mean avg salary there is USD 1,000 per year or per month?
[19:08] <perrito666> jcw4: month
[19:08] <perrito666> altough real avg must be around 600
[19:09] <natefinch> oh ok, you were doing per month
[19:09] <jcw4> still...
[19:09] <perrito666> natefinch: in a country with more than 25% inflation you dont do yearly salary calculations
[19:09] <natefinch> so, 10k is like 2.5x the monthly salary for a median household in the US
[19:09] <natefinch> perrito666: wow, I didn't know it was that bad
[19:10] <jcw4> perrito666: that's nothing, I grew up in Zimbabwe...
[19:10]  * perrito666 running tests for restore
[19:10] <jcw4> :)
[19:10] <natefinch> jcw4: really?
[19:10] <jcw4> Although I wasn't there during the hyperinflation days
[19:10] <jcw4> natefinch: yeah
[19:10] <natefinch> jcw4: that is really interesting. What were your parents doing there?
[19:11] <jcw4> My dad is South African - a preacher (not missionary :) )
[19:11] <perrito666> at some point in the 90s we had a currency worth as much as the dolar which was fake, at some point that was dropped and since then our currency is loosing weight which drives the price up
[19:11] <jcw4> my mom is American
[19:11] <jcw4> perrito666: how do people handle inflation?
[19:11] <jcw4> buy durable goods and sell them later?
[19:12] <perrito666> jcw4: nope, they buy dollars driving inflation even higher
[19:12] <perrito666> and land or appartments driving the prices of real state also up
[19:12] <perrito666> :p
[19:12] <jcw4> :( Zimbabwe tried to make that illegal
[19:12] <perrito666> so did we
[19:12] <jcw4> but they gave up eventually
[19:13] <perrito666> there is a large market for parallel dollar
[19:13] <perrito666> which is 35% higher than official
[19:13] <perrito666> and there is fiscal pressure
[19:13] <jcw4> yeah... danger pay!
[19:13] <jcw4> fiscal pressure?
[19:13] <mgz> what's a parallel dollar?
[19:13] <perrito666> if you buy dollars in an official seller you will be investigated by the irs
[19:14] <jcw4> perrito666: gotcha
[19:14] <perrito666> mgz: in countries where there is fiscal control over who aquires dollars there is a black market for currency
[19:14] <jcw4> a parallel black market
[19:15] <natefinch> perrito666: is there interest in bitcoin there?  Not sure if there's enough internet infrastructure / mobile infrastructure to make it feasible to normal folks
[19:15] <natefinch> it's like the ultimate parallel dollar..... though not very stable either, I suppose
[19:15] <perrito666> natefinch: regular people invest more in traditional stuff
[19:16] <perrito666> for instance its customary to buy real state in cash (declaring 1/3 of the price to irs)
[19:16] <perrito666> no one takes credit or morgages
[19:16] <natefinch> heh
[19:16] <natefinch> yeah
[19:16] <jcw4> perrito666: how could you take long term credit I suppose
[19:16] <natefinch> I bet credit is impossible to get for almost anything
[19:16] <perrito666> ironically, people buy cars in 52 or even 60 mensualities
[19:17] <jcw4> mensualities?
[19:17] <jcw4> payments?
[19:17] <natefinch> I guess if the payments are locked to inflation
[19:17] <perrito666> jcw4: yes, thank you
[19:17] <natefinch> jcw4: monthly payments
[19:17] <perrito666> natefinch: well my car costs 180U$D per month including insurance
[19:17] <jcw4> from what I've read inflation always favours the debtor
[19:17] <natefinch> jcw4: same word base as menstruation :)
[19:17] <perrito666> lol
[19:17] <jcw4> :)
[19:18] <jcw4> although the creditor could make terms that removed that favor
[19:18] <ahasenack> hi, I'm trying to debug a relation-set failure, it fails with "argument list is too long". I want to see that argument list, but juju-log fails with the same error of course :) Before I start opening files, didn't there use to be a debug setting for charms? So it would log everything?
[19:18] <natefinch> ahh work?  boo.
[19:18] <jcw4> ahasenack: sorry I'm just here for the economics chatter
[19:19] <jcw4> ;)
[19:19] <natefinch> marcoceppi_: ^^ debug setting for charms?   Sorry, I don't know, ahasenack.
[19:19] <ahasenack> some time ago the log used to be like "going to call this"
[19:20] <ahasenack> and then it would do it
[19:20] <ahasenack> and fail, in my case
[19:20] <ahasenack> but the intent was logged and I was able to see the details there
[19:20] <natefinch> ahasenack: google says that can happen if you use *.foo, because bash will expand *.foo to actually be all the different files, and if there's too many, boom
[19:21] <ahasenack> natefinch: well, boom can also happen with silly things like https://bugs.launchpad.net/juju-core/+bug/1274460/comments/1
[19:21] <_mup_> Bug #1274460: juju-log vs. command line length limits <juju-log> <juju-core:Triaged> <https://launchpad.net/bugs/1274460>
[19:21] <ahasenack> juju-log "$output" where $output contains, say, -e stuff
[19:21] <ahasenack> but ok, I'll add something to write this stuff to a file and inspect the file
[19:26] <marcoceppi_> ahasenack: run juju debug-hooks
[19:26] <natefinch> ahh right, duh
[19:27]  * natefinch likes the way you can summon people on irc to swoop in and save the day.
[19:27]  * natefinch gives marcoceppi_ a cape.
[19:27] <ahasenack> it's relation_set() from charm helpers that is crashing
[19:28] <ahasenack> but I'm debugging it now
[19:29] <ahasenack> I think at some point in time a default changed in juju and DEBUG logging was turned off, that's what I wanted to re-enabled
[19:29] <ahasenack> re-enable
[19:31] <perrito666> natefinch: backup restore using oplog workls
[19:31] <perrito666> works even
[19:31] <perrito666> at least the restored machine is functional
[19:31] <natefinch> ahasenack:  juju set-environment logging-config "unit=DEBUG"
[19:32] <ahasenack> natefinch: ah, thanks!
[19:32] <natefinch> ahasenack: (figured it out from juju help logging)
[19:32] <ahasenack> good to know
[19:32] <natefinch> for me too :)
[19:33] <perrito666> I need to leave for a moment now bbl
[19:33] <natefinch> perrito666: thanks for figuring that out
[19:34] <perrito666> the only difference is that we will need the password for admin to to the backup, but that is something easy if we are part of api
[19:34] <natefinch> perrito666: yep
[19:53] <jcw4> fwereade: if you happen to get back on again tonight I'd like your approval to merge https://github.com/juju/juju/pull/33
[22:26] <perrito666> what is the preferred way to call external binaries?
[23:24] <jcw4> menn0: weird your comments showed up in my email but not in github
[23:25] <jcw4> I'm going to add that errors stuff in and then hope for a merge :)  I can do it myself now, but I'd like fwereade to at least nod :)
[23:25] <menn0> jcw4: for one comment today I added it then figured out it was dumb so I deleted it. That could by why.
[23:25] <jcw4> menn0: lol
[23:25] <jcw4> menn0: it was a good comment
[23:25] <jcw4> menn0: I should really add comments there to clarify
[23:26] <menn0> jcw4: the one about actionMarker vs actionResultMarker? yeah a comment could help
[23:26] <jcw4> menn0: yep
[23:26] <menn0> jcw4: also, with the comments describing the structures of the action and actionresult ids it might be helpful to show an example of each
[23:26] <menn0> that would make it super clear
[23:26] <jcw4> menn0: +1
[23:27] <jcw4> menn0: godoc doesn't support any markup right?
[23:27] <menn0> you're asking the wrong person. I'm fairly new to Go.
[23:27] <menn0> brb
[23:27] <jcw4> :)
[23:51] <menn0> jcw4: back again. had to deal with the kids for a bit
[23:51] <jcw4> those kids... :)
[23:51] <jcw4> mine will be home from a day at the amusement park soon