[00:35] <thumper> wallyworld: I finally have tests for the golxc clone stuff
[00:35] <wallyworld> yay
[00:35] <thumper> wallyworld: required me putting the checkers into "github.com/juju/testing"
[00:35] <thumper> slightly earlier than I thought
[00:35] <thumper> but, hey, it needed doing
[00:35] <wallyworld> not a bad thing
[00:35] <thumper> right
[00:35] <thumper> just pushing now
[00:36] <thumper> wallyworld: https://code.launchpad.net/~thumper/golxc/clone/+merge/209790 is now up to date
[00:36] <wallyworld> ok
[00:37] <thumper> it isn't perfect, but better than nothing IMO
[00:40] <thumper> wallyworld: ta
[00:40] <wallyworld> np
[00:40] <thumper> wallyworld: also, I have another that you reviewed first, and I moved stuff
[00:40] <wallyworld> ok
[00:42] <thumper> wallyworld: https://codereview.appspot.com/72210043/
[00:42] <thumper> wallyworld: I think it was me moving the lsb-release function
[00:42] <thumper> which I did
[00:42] <wallyworld> ok
[00:44] <wallyworld> thumper: how about extracting a common method to parse the lsb-release file, taking as a param the name of the field (DISTRB_CODENAME  or DISTRIB_RELEASE) to extract
[00:45] <thumper> wallyworld: seriously?
[00:45]  * thumper grumbles
[00:45] <wallyworld> well it is cut and paste code
[00:45] <wallyworld> but feel free not to i guess
[00:45] <wallyworld> your call
[00:46]  * thumper will do it if we touch a third time, how's that?
[00:46] <wallyworld> ok
[00:46] <wallyworld> suppose
[00:47] <thumper> geez
[01:04] <davecheney> wut ?!?
[01:04] <davecheney> http://paste.ubuntu.com/7070987/
[01:21] <thumper> davecheney: which provider?
[01:23] <axw> davecheney: in environs/tools/tools.go, does "toolsConstraint.Arches" contain ppc64?
[01:23] <axw> thumper: that bit should be provider independent I think, as it's uploading tools
[01:25] <thumper> axw: the reason we use the combined output is for testability
[01:25] <thumper> axw: we have the hook thing to replace the output
[01:26] <thumper> axw: it doesn't do one for stdout/stderr just yet
[01:27] <axw> thumper: I guess that's fine since you should never have stdout & stderr at the same time, though I still think it'd be good to add the string to the error
[01:27] <thumper> I agree it would be good
[01:27] <thumper> perhaps we add a new test function :-)
[01:27] <axw> thumper: I was thinking back to ssh things, but in that case stdout/stderr were mixed - not relevant here
[01:27]  * thumper nods
[01:28] <thumper> I did steal one of your ideas though...
[01:28] <thumper> https://github.com/juju/testing/blob/master/cmd.go, with PatchExecutableAsEchoArgs and AssertEchoArgs
[01:29] <axw> cool :)
[01:31] <thumper> waigani: standup
[02:02] <thumper> axw: could I get you to take a look at this too? https://codereview.appspot.com/73300043/
[02:02]  * thumper goes to review ian's branch
[02:04] <axw> sure
[02:13] <davecheney> axw: local provider
[02:13] <davecheney> hang on
[02:13] <davecheney> maybe my ppc change didn't land
[02:13]  * davecheney checks
[02:17] <davecheney> axw: thumper could I get a set of eyeballs on https://codereview.appspot.com/69980044/
[02:18] <axw> sure, just after thumper's one
[02:18] <davecheney> kk
[02:18] <axw> davecheney: it's already reviewed - antying in particular you want looked at?
[02:18] <axw> or it's landed and still not working?
[02:18] <axw> no not landed...
[02:19] <davecheney> not landed, should be trivial review
[02:24] <axw> thumper: reviewed yours
[02:24] <thumper> axw: ta
[02:25] <axw> davecheney: "uname -m" returns what?
[02:30] <davecheney>  uname -m
[02:30] <davecheney> ppc64le
[02:30] <davecheney> WHAT!
[02:30] <davecheney> we've all be calling this ppc64el !!
[02:31] <davecheney> hmm, might have to fsck with that regex
[02:31] <davecheney> going to whinge in a channel
[02:31] <davecheney> bbsd
[02:32] <axw> davecheney: el is just for dpkg I think, kernel calls it le (which makes more sense to me...)
[02:33] <mwhudson> el is a funny computron joke, right?
[02:33] <mwhudson> at least i always assumed that was the explanation for armbe/armel
[02:34] <axw> hah
[02:34] <axw> never thought of it like that :)
[02:35] <davecheney> yup, that is the joke
[02:35] <axw> so blame it on humourless kernel developers ;)
[02:35] <davecheney> i think it comes from byte order marks
[02:35] <davecheney> but probably goes back decades before that
[02:36] <davecheney> mwhudson: i'm going to complain to those guys in that channel about this
[02:36] <davecheney> the archive is called pppc64el ffs!
[02:36] <mwhudson> davecheney: my side of the fence just has aarch64 vs arm64, at least they are easier to tell apart :-)
[02:36] <axw> davecheney: also, the GOARCH is ppc64?
[02:37] <axw> heh
[02:37] <mwhudson> davecheney: i don't actually know which channel you mean, but have fun :)
[02:38] <davecheney> right, ask expected i've been told i'm holding it wrong
[02:43] <davecheney> mwhudson: axw sorry mate, https://bugs.launchpad.net/juju-core/+bug/1290654
[02:43] <_mup_> Bug #1290654: juju must not rely on the output of uname -m <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1290654>
[02:44] <axw> okey dokey
[02:44] <axw> davecheney: although, we may want to support non-dpkg OSes at some point, which renders that bug invalid
[02:45] <davecheney> axw: please don't shoot the messenger, i'm as unhappy about this as you are
[02:45] <davecheney> axw: given how non dpkg os's keep getting pushed off indefinitely, lets leave that til it actually is a problem
[02:51] <davecheney> so, the fire alarm has been going off for quite a while now
[02:51] <davecheney> nobody appears too concerned
[03:12] <thumper> axw: trying to use utils.CopyFile, but it makes my test fail :-(
[03:14] <thumper> axw: http://paste.ubuntu.com/7071362/
[03:14] <thumper> axw: without that diff, tests pass, with that diff, fail
[03:15] <thumper> http://paste.ubuntu.com/7071364/
[03:15] <axw> thumper: back to front?
[03:15] <axw> dest first
[03:15] <thumper> ah...
[03:15] <thumper> ffs
[03:15] <thumper> why?
[03:15]  * axw shrugs
[03:16] <axw> asm? :)
[03:16] <thumper> well that fixed it :-)
[03:33] <axw> wallyworld_: oops, thanks for picking up the copy and paste error :)
[03:33] <wallyworld_> np :-)
[03:34] <axw> wallyworld_: if I were to make a helper for the path, then probably all the tests should change. I'd rather leave that to another MP if you don't mind...
[03:34] <wallyworld_> sure
[03:34] <axw> need to do a bunch of tidying up I think
[03:34] <wallyworld_> yeah
[03:44] <thumper> grr!!!!!
[03:44] <thumper> my branch has failed to land about 5 times so far
[03:44] <thumper> with different intermittant failures
[03:44] <thumper> All related to mgo starting AFAIKT
[03:44] <thumper> s/K/C/
[03:44] <wallyworld_> been there done that :-(
[03:44] <thumper> no idea what causes the failures
[03:45] <wallyworld_> thumper: you happy with the changes to my branch now?
[03:46] <thumper> wallyworld_: just looking
[03:46] <wallyworld_> ok :-)
[03:49] <thumper> emailed
[03:49] <axw> wallyworld_: is the juju bot running tests for gwacl? seems to lacking a branch for gocheck
[03:49] <wallyworld_> axw: it was. but maybe when it was set up again that was left out
[03:50] <wallyworld_> thumper: ta. yes, find tools will change for sure i think. but there's an api now :-)
[03:50] <thumper> right
[03:53] <thumper> axw: https://codereview.appspot.com/73300043 in order to better match the config file, I also moved the mounting of the logdir to after creation (it needed to be done anyway)
[03:54] <axw> sounds good, looking
[04:02] <axw> wallyworld_, thumper: I don't have the bot creds, would one of you please branch launchpad.net/gocheck into  /home/tarmac/gwacl-trees/src/launchpad.net/gocheck on the bot?
[04:02] <wallyworld_> ok
[04:02] <axw> thanks
[04:03] <thumper> I don't have creds either :-(
[04:03] <thumper> wallyworld_: while you're there, care to "go get github.com/juju/testing" ?
[04:03] <wallyworld_> suppose
[04:03] <thumper> ta
[04:03] <thumper> omg, my branch landed sixth time lucky
[04:05] <wallyworld_> axw: done
[04:06] <axw> thanks wallyworld_
[04:06] <wallyworld_> np
[04:06] <wallyworld_> thumper's is done too
[04:07] <thumper> wallyworld_: you the man!
[04:07] <wallyworld_> sometimes
[04:10] <thumper> axw: are you ok with me using the combined output for testing purposes? https://codereview.appspot.com/73310043/
[04:10] <thumper> wallyworld_: meaning sometimes you are the woman?
[04:11] <wallyworld_> why yes
[04:11] <wallyworld_> how did you know
[04:11] <axw> thumper: yeah sorry, I will lgtm
[04:11] <thumper> ta
[06:08] <davecheney> axw: i'd really like to land this sukka today, https://codereview.appspot.com/69980044/
[06:09] <axw> davecheney: looking
[06:15] <axw> davecheney: lgtm
[06:15] <davecheney> axw: ta
[06:15] <davecheney> landing
[06:33] <jam> wwitzel3, thumper: FWIW when you get a test suite failure about replicaSet, that *usually* is what breaks the bot (I believe the test is waiting for mongod to start, but times out and then leaves it alive, which leaves the flock open which blocks future test runs)
[06:35] <davecheney> or not ... replicaset_test.go:223: c.Assert(err, gc.IsNil)
[06:35] <davecheney> ... value *errors.errorString = &errors.errorString{s:"Error getting replset config : no reachable servers"} ("Error getting replset config : no reachable servers")
[06:40] <jam> davecheney: known intermittent test failure, you should reapprove, I'll check that the bot is running ok
[06:41] <jam> davecheney: maybe you already did, since the bot is working on that branch as of :37 which is just after you commented
[08:35] <rogpeppe> mornin' all
[08:36] <dimitern> rogpeppe, mornin :)
[08:36] <rogpeppe> dimitern: hiya
[08:37] <dimitern> rogpeppe, can you take a look at this? https://codereview.appspot.com/72860045/
[08:37] <rogpeppe> dimitern: will do in a little bit
[08:37] <dimitern> rogpeppe, ta
[08:37] <rogpeppe> dimitern: (when i've had more than 20 seconds to catch up on my email :-])
[08:38] <dimitern> :) sure
[09:52] <dimitern> rogpeppe, ping
[09:52] <rogpeppe> dimitern: i'm looking at your review now, BTW
[09:53] <voidspace> how do I update dependencies.tsv?
[09:54] <voidspace> when adding github.com/juju/ratelimiter as a new dependency
[09:54] <rogpeppe> voidspace: go get launchpad.net/godeps
[09:54] <voidspace> rogpeppe: running
[09:55] <rogpeppe> voidspace: then make sure that all your deps are currently up to date, by running godeps -u dependencies.tsv
[09:56] <rogpeppe> voidspace: then run godeps -t $(go list launchpad.net/juju-core/...)  > dependencies.tsv
[09:57] <voidspace> rogpeppe: and that has added the new dependency
[09:57] <voidspace> rogpeppe: thanks
[09:57] <rogpeppe> voidspace: cool
[09:57] <voidspace> and changed the order of another in the list
[09:57] <voidspace> right, I need to stash that instruction somewhere
[09:57] <rogpeppe> voidspace: the godeps -t line is in the CONTRIBUTING file
[09:58] <voidspace> rogpeppe: ah, I read the README but not that one
[09:58] <voidspace> rogpeppe: my bad, thanks
[09:58] <rogpeppe> dimitern: in general, i would have much preferred it if you had separated that large CL into several smaller ones
[09:59] <voidspace> I've finally got vim killing trailing whitespace on save
[10:04] <rogpeppe> voidspace: some people find it nicer just to gofmt on save
[10:04] <voidspace> rogpeppe: that's not a bad call
[10:04] <rogpeppe> voidspace: or, better, run goimports on save (that way you rarely have to worry about adding or removing imports)
[10:05] <voidspace> rogpeppe: does goimports run go fmt too?
[10:05] <rogpeppe> voidspace: yes
[10:06] <voidspace> rogpeppe: sounds like the option to go for then
[10:06] <rogpeppe> voidspace: (it kind of *is* gofmt, but with additional import-related functionality)
[10:06] <voidspace> rogpeppe: right
[10:07] <rogpeppe> voidspace: in general, any tool that transforms go source code will do the equivalent of gofmt on output
[10:08] <voidspace> rogpeppe: this one? https://godoc.org/code.google.com/p/go.tools/cmd/goimports
[10:08] <voidspace> rogpeppe: there seem to be several forks
[10:08] <rogpeppe> voidspace: yup
[10:08] <rogpeppe> voidspace: that's the canonical one
[10:08] <dimitern> rogpeppe, I know, I was thinking of that
[10:08] <voidspace> rogpeppe: cool, thanks
[10:11] <dimitern> jam, rogpeppe, if we're dropping 1.14 compatibility, then bug 1235217 can be closed and NewEnvFromName code simplified
[10:11] <_mup_> Bug #1235217: old environments should be given .jenv files <jenv> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1235217>
[10:27] <mattyw> dimitern, rogpeppe this merge proposal: https://codereview.appspot.com/51450047/ has totally changed. The meaning of the juju login and juju whoami commands has changed totally in the last couple of days so it's be decided to remove them from this mp - and by some accident of history there should also be a fix for https://bugs.launchpad.net/juju-core/+bug/1285256 in it - do you think I should restart the codereview - or keep it as it
[10:27] <mattyw> is?
[10:27] <_mup_> Bug #1285256: bootstrapping juju from within a juju deployed unit fails <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1285256>
[10:27] <rogpeppe> mattyw: i'll have a look when i've finished the review i'm on
[10:28] <mattyw> rogpeppe, many thanks
[10:31] <rogpeppe> dimitern: could you explain to me the reasoning behind the configstore.Exists function, please?
[10:34] <dimitern> rogpeppe, that's the way we detect if the env is bootstrapped early, so we can report it consistently across all commands except bootstrap and sync-tools
[10:34] <rogpeppe> dimitern: it's only used in one place, right? (in juju.newAPIClient)
[10:35] <dimitern> rogpeppe, well yes
[10:35] <rogpeppe> dimitern: why not just do a ReadInfo in that place?
[10:36] <dimitern> rogpeppe, we might not have a store yet to ReadInfo from
[10:36] <rogpeppe> dimitern: how could that happen?
[10:37] <rogpeppe> dimitern: the only way that i could see is if ~/.juju doesn't exist yet, but that should not happen
[10:38] <dimitern> rogpeppe, well i'd like to be defensive there
[10:38] <rogpeppe> dimitern: i don't understand
[10:39] <rogpeppe> dimitern: if we couldn't create a config store object, how could we ever write an info?
[10:40] <rogpeppe> dimitern: if the NewDisk call fails, we'll return with an error anyway, which is sufficiently defensive, i think
[10:41] <dimitern> rogpeppe, Default() will panic if there's no JujuHome set, which is awkward
[10:42] <rogpeppe> dimitern: huh?
[10:42] <rogpeppe> dimitern: Exists panics in that case too
[10:43] <rogpeppe> dimitern: if juju home isn't set, we *want* to panic - it's something that every juju client program should do
[10:43] <rogpeppe> dimitern: Exists is also wrong in this case because it uses configstore.Default, which at some point in the future may not return a disk-based configstore
[10:44] <dimitern> rogpeppe, exists can be patched for tests
[10:44] <rogpeppe> dimitern: that is, it assumes that configstore.Default returns the same thing as configstore.NewDisk(osenv.JujuHome()), which is breaking the Default abstraction
[10:44] <dimitern> rogpeppe, and let's worry about default not returning a disk-based store when we get there
[10:44] <rogpeppe> dimitern: let's not willfully break abstractions that don't need to be broken, please
[10:45] <rogpeppe> dimitern: i don't understand why we need to patch Exists.
[10:45] <rogpeppe> dimitern: i don't understand the PatchValue in bootstrapEnv
[10:46] <rogpeppe> dimitern: it's easy to "patch" Exists without diving under the covers - we can just create the environ info
[10:47] <wallyworld_> we having a standup? I'm more than happy to skip it :-)
[10:47] <rogpeppe> wallyworld_: probably
[10:47] <rogpeppe> wallyworld_: joining
[10:51] <jam> mgz: poke for standup ?
[10:51] <jam> wallyworld_: ^^ ?
[10:51] <wallyworld_> jam: i'm there
[10:51] <wallyworld_> wrong hangout maybe
[10:51] <jam> wallyworld_: probably, as I don't see you in here
[10:51] <jam> wallyworld_: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[10:56] <voidspace> rogpeppe: a bad photo
[10:56] <voidspace> rogpeppe: https://www.dropbox.com/s/tkmkun6etxju83l/my-setup.jpg
[10:57] <rogpeppe> voidspace: nice!
[10:57] <voidspace> rogpeppe: room for a couple more if I reorganise... ;-)
[10:58] <jam> voidspace: you have a 7th mini monitor if I see it correctly
[10:59] <voidspace> jam: I have a chumby clock
[10:59] <jam> voidspace: one exists inside my home somewhere
[10:59] <voidspace> jam: which is not really a monitor as I only ever run the clock app...
[10:59] <voidspace> jam: heh :-)
[11:14] <mattyw> voidspace, is that a kinesis keyboard I see?
[11:14] <voidspace> mattyw: yep, kinesis advantage. My favourite keyboard of all time. :-)
[11:15] <mattyw> voidspace, I've always wanted to give one  a go - but could never find someone who had one to try out - and I don't feel I can justify the cost
[11:16] <mattyw> ^^ unless I knew I was going to be able to use it
[11:16] <voidspace> mattyw: yep, they're ridiculously expensive - but like a good chair, worth the investment
[11:16] <voidspace> mattyw: I tried one at PyCon one year
[11:16] <voidspace> mattyw: you *have* to touch type (or have a miserable time)
[11:16] <voidspace> mattyw: but if you can touch type (or mostly touch type - it will make you learn fast) then they're awesome
[11:17] <voidspace> mattyw: reach every key without moving your hands
[11:17] <voidspace> mattyw: just rest your palms on the keyboard (rests provided) and the "well design" means you can reach every key with your fingers
[11:18] <mattyw> voidspace, hopefully I'll be able to try yours at some point - I was convinced to buy a mechanical keyboard about 12 months ago - the perfect soundtrack
[11:18] <voidspace> mattyw: when I travel I tend to bring my kinesis split keyboard instead
[11:18] <voidspace> mattyw: the advantage is a bit expensive and bulky to travel with
[11:18] <voidspace> mattyw: but yes, the mechanical switches make them very nice to type with
[11:18] <voidspace> but a bit clacky
[11:23] <mattyw> is fwereade around today?
[11:32] <rogpeppe> mattyw: i don't think so
[11:32] <jam> wallyworld_: you have a review for https://code.launchpad.net/~wallyworld/juju-core/simplestreams-ordering/+merge/210324
[11:33] <wallyworld_> thanks
[11:33] <wwitzel3> jam: on the verbose output / fix for the replica set , I didn't see a reitveld , should I just comment on the diff in lp?
[11:33] <jam> wwitzel3: yeah, I didn't get lbox setup on the new machine, so just LP is fine
[11:34] <wallyworld_> jam: i think sorting is not strictly necessary but "nice"
[11:34] <wallyworld_> hence i put it in the code
[11:38] <voidspace> right, coffee
[11:39] <voidspace> mattyw: Will won't be around until Thursday
[11:56] <dimitern> rogpeppe, are you still on it? :)
[11:57] <rogpeppe> dimitern: yeah
[11:57] <rogpeppe> dimitern: i'll publish my comments so far though
[12:01] <dimitern> rogpeppe, thanks
[12:03] <rogpeppe> dimitern: why the new manual/testing package?
[12:05] <dimitern> rogpeppe, to drop gocheck imports in real code
[12:06] <rogpeppe> dimitern: why not just put the code inside a _test.go file inside environs/manual?
[12:07] <dimitern> rogpeppe, because it's used in environs/manual and provider/manual tests
[12:08] <rogpeppe> dimitern: really?
[12:08] <rogpeppe> dimitern: i only see a manual/testing import inside environs/manual tests
[12:08] <dimitern> rogpeppe, sorry, not in provider/manual - let me take a look
[12:10] <dimitern> rogpeppe, it seems that's true now, ok will move it in environs/manual/fakessh_test.go
[12:10] <rogpeppe> dimitern: thanks
[12:42] <jam> natefinch, rogpeppe: can we have a hangout later tonight to chat about what we need to do for HA ?
[12:43] <rogpeppe> jam: sure
[12:43] <rogpeppe> jam: what time's good for you?
[12:43] <jam> I have family time until about 16:00 UTC, so after that would be ok
[12:44] <jam> rogpeppe: would 16:00 work for you? I think it shouldn't be a problem for Nate
[12:45] <rogpeppe> jam: seems fine for me.
[12:45] <rogpeppe> jam: i guess it might be lunchtime for nate
[12:48] <natefinch> rogpeppe, jam:  1600 is a little tricky because my wife will be getting my daughter from preschool, so I'll have the baby. but 16:30 would work.
[12:48] <jam> natefinch: fine for me
[12:49] <jam> you can also meet with one hand, right? :)
[12:49] <jam> natefinch: rogpeppe: bumped to 16:30
[12:49] <rogpeppe> jam, natefinch: SGTM
[12:49] <natefinch> jam: cool
[12:49] <natefinch> jam: sometimes the kids require three hands :)
[12:59] <rogpeppe> dimitern: rest of review done
[13:08] <dimitern> rogpeppe, tyvm
[13:08] <rogpeppe> dimitern: np
[13:15] <voidspace> rogpeppe: why did you make ratelimit.New Capacity an int64 - expecting some *really* big buckets?
[13:16] <rogpeppe> voidspace: because i wanted to be able to use it for bytes-per-second transfer rates
[13:16] <rogpeppe> voidspace: and 4GB per second isn't beyond the bounds of possibility
[13:16] <voidspace> rogpeppe: heh, ok
[13:16] <voidspace> rogpeppe: so the answer is yes
[13:17] <rogpeppe> voidspace: :-) yeah
[13:39] <sinzui> Looks like bootstrap is broken on precise
[13:39] <sinzui> aws and hp fail
[13:39] <sinzui> as does azure
[13:39] <sinzui> trusty passed
[13:39] <natefinch> sinzui: how is it failing?
[13:40] <sinzui> Not must information http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/aws-deploy/880/console
[13:40] <sinzui> hp is no better http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/hp-deploy/822/console
[13:41] <sinzui> I will try to gather a --debug level bootstrap
[13:41] <natefinch> sinzui: I suspect those are the failures I was seeing on trusty yesterday
[13:41] <sinzui> but trusty passed on CI
[13:42] <natefinch> sinzui: it fails for me, though.  I wonder why.  I had the same bootstrap failed: rc: 1  error
[13:42] <sinzui> interesting
[13:43] <sinzui> I am going to wait for CI to finish. I will know all the places it failed
[13:43] <natefinch> sinzui: for me, I did some debugging and it was timing out trying to ssh into the instance... I don't know if you're seeing the same problem
[13:44] <natefinch> sinzui: I had to had quite a bit of additional code to figure that out, since that RC 1 error is not exactly informative as-is
[13:44] <sinzui> natefinch, was it a timeout, or do you believe there was network issues preventing success
[13:46] <natefinch> sinzui: it was a timeout.  I was able to manually create an amazon instance and ssh into it.  I'm about to try juju bootstrapping a machine and then manually ssh'ing into it.
[13:47] <sinzui> oh, even manual deploy failed
[13:54] <natefinch> sinzui: weird, yeah, I can ssh into the machine just fine, but juju's attempt fails.... this call is essentially what I did manually to have it work:
[13:54] <natefinch> 2014-03-11 13:52:33 DEBUG juju.utils.ssh ssh_openssh.go:147 running: ssh -o "StrictHostKeyChecking no" -o "PasswordAuthentication no" -i "/home/nate/.juju/ssh/juju_id_rsa" -i "/home/nate/.ssh/id_rsa" "ubuntu@107.21.197.67" '/bin/bash'
[13:54] <natefinch> sinzui: I just did $ ssh -i ~/.ssh/id_rsa ubuntu@107.21.197.67
[13:55] <sinzui> interesting
[13:56] <natefinch> sinzui: I have to get on a UDS meeting in 5 minutes, but afterward I can do some more investigation.   Other people seem not to be having this problem, so maybe there's an environmental problem that is making Juju unhappy.
[14:05] <natefinch> sinzui: evidently had the days mixed up, so no UDS thing for me (at least not for me to be in).  Lemme see if I can figure out what's going on.
[14:08] <sinzui> natefinch, thank. CI replayed the deploy tests for precise and all failed. They failed 5 times in a row
[14:10] <voidspace> right, lunch
[14:10]  * voidspace lurches
[14:51] <hatch> http://askubuntu.com/questions/432679/getting-git-error-on-juju-charm-upgrade <--- this seems like a bug to me. The user shouldn't have to configure git to use juju....?
[14:54] <natefinch> hatch: I know we use git for charm upgrades, but I wouldn't think we'd require git to be configured in any particular way, especially on juju-deployed machines.
[14:54] <natefinch> rogpeppe, mgz, dimitern: can you guys bootstrap aws etc?  my bootstrap times out trying to connect to the instance
[14:55] <hatch> natefinch yeah that's what I was thinking. I've also never ran into that issue and I've done a lot of bare-bones installs....I was just trying to get an idea if I should comment that he should file a bug
[15:10] <sinzui> natefinch, I am testing hp cloud...and it is looking better. I am wondering if the issue relates to user setup. CI runs under a very restricted user
[15:10] <sinzui> natefinch, nm, it just bailed
[15:11] <natefinch> sinzui: doh
[15:11] <natefinch> sinzui: honestly, it's probably better that way.  Some weird user setup is harder to figure out than a general failing
[15:11] <sinzui> HP died at
[15:11] <sinzui> Installing package: --target-release 'precise-update/cloud-tools' 'git'
[15:12] <natefinch> that's odd
[15:14] <sinzui> natefinch, I think cloud-tools might be at issue. That would explain why trusty is happy
[15:17] <natefinch> sinzui: I think I figured out part of my own problem... some debugging code I had put in to debug a different problem was inadvertently screwing up SSH.
[15:20] <sinzui> natefinch, I updated bug with the info I just learned https://bugs.launchpad.net/juju-core/+bug/1290890
[15:20] <_mup_> Bug #1290890: juju 1.17.5 RC cannot deploy to precise <ci> <deploy> <precise> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1290890>
[15:24] <mattyw> does anyone know why a merge proposal might suddenly go insane? https://codereview.appspot.com/51450047/
[15:26] <sinzui> natefinch, Hey, we are probably using different tools. I am testing using the 1.17.5 release candidate tools that were placed in each cloud. Are you using upload tools?
[15:32] <natefinch> sinzui: I'm using trunk without upload tools.  I think I've used upload tools without it making a difference.
[15:33] <sinzui> natefinch, I agree, I just wanted you to know how juju got the tools in the ci tests and my one tests
[15:34] <natefinch> sinzui: cool
[15:34] <natefinch> mattyw: what's insane about that?  (not sure what it should look like).   I do know that sometimes rietveld gets confused, and you need to repropose/
[15:35] <mattyw> natefinch, I'll try that - I was expecting 5 files changed - I got almost all of core
[15:40] <sinzui> natefinch, I don't see git in the archive. http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/g/
[15:48] <natefinch> sinzui: what is in the archive and how it gets there is a mystery to me
[15:48] <jam> natefinch: rogpeppe, I'm going to try to be back in time for our hangout, but I have to go do some grocery shopping. If I'm not back in time, please start talking about it without me, I'llbe on  as soon as I can
[15:48] <rogpeppe> jam: ok
[15:48] <natefinch> jam: k
[15:50] <sinzui> natefinch, the team that owns the archive, which includes jamespage, backport new software to precise so that our cloud tools are always modern.
[15:51] <sinzui> natefinch, I don't think anyone asked for git to be backported, and ot probably doesn't. Juju just assumes if it needs git, it needs to get it from the cloud-archive. Just like it does for mongodb-server
[15:51] <natefinch> sinzui: ahh interesting
[15:52] <natefinch> sinzui: doersn't seem like that should have changed recently, thoughj
[15:52] <sinzui> natefinch, I am going to bootstrap hp with 1.17.4 and see if it gets git from a different location
[16:19] <sinzui> natefinch, I updated Bug #1290890. 1.17.4  didn't install git from cloud-tools. The regression is in code that always want to install precise packages from cloud-tools
[16:19] <_mup_> Bug #1290890: juju 1.17.5 RC cannot deploy to precise <ci> <deploy> <precise> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1290890>
[16:19] <natefinch> sinzui: interesting, thanks for doing all that work.
[16:21] <voidspace> yay, my tests compile
[16:21] <voidspace> they don't *do* anything, but they compile ;-)
[16:21] <voidspace> actually, they start a loop with the a testInstanceGettter instead of a real environ and then quit, so not true that they do *nothing*
[16:23] <wwitzel3> it's the small victories
[16:25] <wwitzel3> I decided to make my maas configuration "better" .. by using a bridged virtual interface that used port fowarding and NAT via iptables so that as I moved locations, I wouldn't have issues with my maas getting confused by the network setup.
[16:26] <natefinch> wwitzel3: you're a braver man than I
[16:27] <natefinch> wwitzel3: last time I touched my iptables I couldn't print for a month
[16:30] <voidspace> haha :-)
[16:34] <rogpeppe> natefinch: https://plus.google.com/hangouts/_/canonical.com/discuss-ha?authuser=1
[16:59] <bodie_> is there a diagram illustrating the basic architecture of juju anywhere or should I just break down the source for myself?
[17:01] <voidspace> rogpeppe: ping
[17:02] <voidspace> rogpeppe: you able to help with a go question?
[17:02] <rogpeppe> voidspace: in a call right noew
[17:02] <voidspace> rogpeppe: okey-dokey
[17:03] <voidspace> natefinch: fancy helping me with a go issue?
[17:04] <natefinch> voidspace: in the same call as Roger, sorry :)
[17:05] <voidspace> natefinch: heh, ok
[17:05] <voidspace> I'll figure it out
[17:06] <wwitzel3> voidspace: now I'm curious :)
[17:06] <voidspace> hah
[17:07] <voidspace> wwitzel3: 	 I get the following build error
[17:07] <voidspace> wwitzel3: receive from send-only type chan<-
[17:07] <voidspace> and I can't see how the declaration/creation of the channels are incorrect
[17:07] <wwitzel3> branch or pastebin?
[17:07] <voidspace> I'm about to resort to google, I assume it's a simple error
[17:07] <voidspace> the error is from line 184 of this diff:
[17:08] <voidspace> https://code.launchpad.net/~mfoord/juju-core/instancepoller-aggregate/+merge/209966
[17:08] <voidspace> instanceInfoReq is defined on line 59
[17:09] <natefinch> chan type without an arrow is send/receive, chan type with arrow is either receive only <-chan or send only chan<-
[17:10] <bodie_> there's no syntax like arbitrary syntax
[17:11] <voidspace> natefinch: ah, the channel is incorrectly defined I believe
[17:11] <voidspace> or I'm using it incorrectly
[17:11] <voidspace> surely for a channel to be *useful* someone has to be able to send on it and someone has to be able to receive
[17:11] <natefinch> voidspace: arrow points in direction of data flow  (into or out of channel), always pointing left
[17:12] <voidspace> natefinch: what good is a channel I can write to, but no-one can read from?
[17:12] <voidspace> I guess I'm missing a piece of the puzzle :-)
[17:12] <natefinch> voidspace: you can't start with a read or write only channel, but you can return one from a function or or pass one into a function, to restrict what someone else can do with it
[17:12] <voidspace> ah...
[17:12] <bodie_> interestijng
[17:13] <natefinch> voidspace: so you start with a read/write, return it to someone else defined as read only, then you know that person can't send on it
[17:13] <voidspace> natefinch: thanks, for now I've relaxed the declaration as I don't care about stopping other people doing things
[17:14] <wwitzel3> voidspace: so was the fix changing line 71 of that diff?
[17:14] <wwitzel3> 61
[17:14] <voidspace> wwitzel3: yep, 61
[17:15] <voidspace> cool, it compiles, runs and blows up in interesting ways!
[17:15] <wwitzel3> ship it
[17:15] <voidspace> which is right as I configured the test data for it to return
[17:15] <voidspace> hah
[17:15] <voidspace> wwitzel3: the other fix would have been to create the channel and then set it on the instanceInfoReq struct
[17:16] <voidspace> wwitzel3: because I'm creating it in the constructor the compiler creates one of the type specified
[17:16] <voidspace> which I then can't read from
[17:16] <voidspace> yay for type inferencing
[17:17] <wwitzel3> :)
[17:17] <arosales> Hello, could I get confirming the joyent provider is being pulled into the  1.18 release?
[17:26] <dstroppa> mgz: has the joyent-provider-storage mp landed?
[17:27] <rick_h_> arosales: very interested in that answer for quickstart as well if you can ping when you hear
[17:30] <mgz> dstroppa: no, there was some bot issues, and I forgot to go back and land after fixing
[17:30] <mgz> dstroppa: I'll do it now
[17:31] <dstroppa> mgz: thanks
[17:32] <sinzui> natefinch, r2403 is probably the issue. That revision changed cloud init to address issues for precise on maas. CI is running the previous revision . We will know in 30 minutes if CI loves it
[17:32] <natefinch> sinzui: ahh, good, I hope it helps
[17:49] <sinzui> natefinch, r2403 is the bad rev. CI passed aws, hp, manual, and local
[17:50] <natefinch> sinzui: awesome
[18:04] <sinzui> wwitzel3, Juju CI hates you. Don't take it personally. r2403 introduced by your branch to fix bug 1289316 prevents precise deployments.
[18:04] <_mup_> Bug #1289316: lxc not installed from ubuntu-cloud.archive on precise <lxc> <maas> <precise> <regression> <juju-core:Fix Committed by wwitzel3> <https://launchpad.net/bugs/1289316>
[18:05] <sinzui> wwitzel3, Bug #1290890 documents that juju is attempt to install git and other packages from the cloud-archive. They should come from ubuntu.
[18:05] <_mup_> Bug #1290890: juju 1.17.5 RC cannot deploy to precise <ci> <deploy> <precise> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1290890>
[18:05] <voidspace> can you define types in a closure in Go?
[18:05] <voidspace> or methods?
[18:06] <voidspace> really I want a method to use a closure
[18:06] <voidspace> I can just add more state to the struct to mimic it if not
[18:06] <sinzui> wwitzel3, natefinch: The safe choice is to revert r2403, but maybe you see how to ensure just mongodb and lxc are installed from the cloud archive (though there may be other tools that need to come from there too_
[18:08] <wwitzel3> sinzui, natefinch: ok, I remember talking about it and it was determined that any LTS release should just have everything come from cloud archive, but it is easy enough to change.
[18:10] <sinzui> wwitzel3, I think that is a sensible decision, but did some arrange for each package to be there?
[18:11] <sinzui> We need to maintain a list of packages that the server team needs to copy or backport. They may have rules against copies
[18:12] <sinzui> ^ jamespage is it problematic to copy a list of packages from ubuntu to the cloud archive to make it easy for juju to choose where to install packages from
[18:13] <wwitzel3> sinzui: no, I didn't know that I needed to ensure that the list of packages was updated.
[18:14] <wwitzel3> sinzui: so is the fix getting those packages on to cloud archive for precise or reverting r2403?
[18:15] <sinzui> wwitzel3, The issue is we want to release at any hour. We cannot because your rev simply doesn't work. There is no point in testing the revs that are about to land. reverting is best, but just installing mongodb-server and lxc from cloud-archive is also a fix
[18:16] <mgz> a straight revert for now sounds fine
[18:18] <wwitzel3> sinzui, mgz: ok, so revert will address 1290890, then I need to reopen 1289316, and make the changes for only lxc and mongo-server to install from cloud archive?
[18:18] <bodie_> is the preconfigured vagrant juju box suitable for core dev?
[18:18] <wwitzel3> mgz: I also have no idea how to do a revert :)
[18:18] <voidspace> I have a sanely failing test - the loop is running, receiving my request, and correctly returning the error from the testInstanceGetter
[18:18] <sinzui> wwitzel3, yes, that is a viable path
[18:18] <voidspace> now to make testInstanceGetter do something other than return an error...
[18:19] <voidspace> which means I need something implementing instance.Instance, yay for interface embedding I guess
[18:19] <wwitzel3> sinzui: or revet, which fixes the regression, reopen and have it pending the other packages get added to cloud archive?
[18:19] <wwitzel3> revert
[18:20] <sinzui> wwitzel3, revert, reopen. We can ask the server team if they can put all packages in the archive. This might not be good though if every new dep needs to be vetted by another team and scheduled to their own cadence.
[18:22] <wwitzel3> sinzui: ok, sounds good, thanks
[18:24] <wwitzel3> mgz: can you walk me through the process of reverting?
[18:25] <mgz> wwitzel3: basically, you merge the inverse of the change, then propose that (and get approved, or self approve)
[18:30] <mgz> so, make a new branch, `bzr merge co:master -r2403..2402`
[18:30] <mgz> check that, commit, propose
[18:31] <mgz> then to reland later, you want to merge trunk back into your feature branch, reject the changes, and commit, but that can be done later
[18:34] <bodie_> ugh.  anyone know why i'm getting this? http://pastebin.centos.org/8371/
[18:34] <bodie_> (using the juju box as suggested)
[18:34] <bodie_> the virtualbox GUI didn't have anything useful afaict
[18:35] <bodie_> is there some config step I'm missing...?
[18:35] <bodie_> bleh
[18:45] <wwitzel3> mgz: can you take a look https://code.launchpad.net/~wwitzel3/juju-core/lp-1290890-revert-2403/+merge/210474
[19:22] <rogpeppe> voidspace: sorry about lack of reply - we've only just finished on the HA estimation
[19:22]  * rogpeppe must stop now
[19:22] <rogpeppe> g'night all
[19:28] <voidspace> g'night from me too
[19:37] <jam> natefinch: I know you were looking at changing the mongodb dependency to probe for the upstart job on the server rather than the client, is that scoped on the Board ?
[19:37] <jam> and/or is it in a state that we can hand it to someone else to have you focus on HA ?
[19:38] <jam> natefinch: also, I set up the board in 3 distinct HA lanes under TODO, which maps to how I think about what the implementation flows would be, can you look over it and see what you think?
[19:38] <jamespage> sinzui, sorry - not quite sure what you need
[19:40] <sinzui> jamespage, The devs decide juju should install all precise deps (git, cpu-checker, etc) from the cloud archive. They never asked if the server team would support that
[19:40] <jamespage> sinzui, well that was a bad decision
[19:40] <sinzui> jamespage :)
[19:40] <jamespage> sinzui, heres the list
[19:40] <jamespage> http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/cloud-tools_versions.html
[19:41] <sinzui> The the revision is being reverted
[19:41] <jamespage> sinzui, ack
[19:43] <sinzui> jamespage, I updated the bug with that list thanks. I think an informed decision will be made now
[19:43] <natefinch> jam: the mongodb stuff is done and in the code I am working on landing.
[19:45] <natefinch> jam: the lanes look good to me
[19:48] <jamespage> sinzui, np
[19:48] <jamespage> sinzui, no one is doing anything on the juju-mongodb -> juju-db rename are they?
[19:48] <jamespage> if we do that it needs to be co-ordinated
[19:54]  * thumper frowns
[19:54]  * thumper looks at wwitzel3
[19:55] <thumper> wwitzel3: you couldn't have known, but you have broken my branch
[19:55] <thumper> wwitzel3: you put the machine config back into AddAptCommands
[19:55] <thumper> wwitzel3: I have been trying to keep it independent from MachineConfig because I'm using it elsewhere...
[19:56] <thumper> wwitzel3: I can pull it back out by passing the target release in as a param...
[20:14] <thumper> wwitzel3: also, re: https://code.launchpad.net/~wwitzel3/juju-core/lp-1290890-revert-2403/+merge/210474 you were missing a commit message so the bot was ignoring it (I fixed that for you)
[20:14] <sinzui> jamespage, I have not done anything. I think natefinch is landing changes that assume the db is named juju-mongodb
[20:17] <natefinch> sinzui: my code doesn't care what the package name is, just what the filename is.  as long as it's installed in /usr/lib/juju/bin/mongod, my code doesn'tcare
[20:18] <sinzui> natefinch, excellent
[20:25] <wwitzel3> thumper: well my revert will land and I can make the fix for not passing in MachineConfig
[20:25] <thumper> wwitzel3: I see the reversion change
[20:26] <wwitzel3> thumper: you mean the increase? yeah, I just: bzr merge -r2403..2402 which reverted back to r2402 but under 2404
[20:27] <wwitzel3> thumper: if there is a better way, I can redo it
[20:27] <thumper> no, that is the right way
[20:27] <thumper> I'll just wait for it to land before I continue with my particular change
[20:28] <wwitzel3> thumper: rgr, thanks for fixing the commit message as well
[20:28] <thumper> np
[20:28] <wwitzel3> thumper: does -m with bzr not set that?
[20:28] <thumper> yes, but not on the merge proposal
[20:28] <thumper> there is a subtlety there
[20:29] <wwitzel3> thumper: ahh right, ok, before I used lbox which did it for me
[20:29] <wwitzel3> thumper: got it, thanks
[20:29] <thumper> the description is what people use to describe the change
[20:29] <thumper> actually, lbox only sets the description
[20:29] <thumper> you need to set the commit message on launchpad when approving
[20:29] <thumper> otherwise the bot ignores it
[20:29] <natefinch> wwitzel3: forgetting the commit message is a mistake I made for the first like 4 months here
[20:29] <thumper> most likely this will all change when we move the code anyway
[20:30] <wwitzel3> thumper: got it, thanks :)
[20:30] <wwitzel3> natefinch: hah, I suspect it will happen to me a few more time
[20:31] <wwitzel3> coming from git and this being my first time with bzr, I actually quite like the workflow of it, I imagine you could have the same flow with git, but in my experience most don't
[20:32] <wwitzel3> sinzui: the revert has landed in trunk re lp:1290890
[20:33] <wwitzel3> oh, go bot updated the bug for me .. well that was nice of it
[20:34]  * thumper goes to pull trunk again
[20:34] <sinzui> thank you wwitzel3
[20:34] <wwitzel3> thumper: ok, so now I want to address the MachineConfig being passed in that broke you, on my old branch do I just revert the revert? Fix and push?
[20:34] <wwitzel3> sinzui: np
[20:34] <thumper> wwitzel3: the reversion you just landed un-broke me
[20:34] <thumper> wwitzel3: I just suggest that for the function pass in the series not the entire machine config
[20:35] <thumper> and that _should_ be fine
[20:35] <thumper> remember that it will be called from somewhere that doesn't have a machine config object
[20:35]  * thumper is about to write the plugin
[20:36] <hazmat> thumper, ping.. got time for a pre-implementation call?
[20:36] <thumper> natefinch: any idea how to fix the intermittent replicaset bug?
[20:36] <thumper> hazmat: sure
[20:37] <natefinch> thumper: jam had a fix for it, I think it's proposed, lemme go look
[20:38] <wwitzel3> thumper: the revert caused 1289316 to be broken again, so I guess I'm wondering what the easiest way is to get my branch back to 2403 and fix the issues?
[20:38] <wwitzel3> thumper: can I just revert the revert? or checkout to a specific revision?
[20:40] <thumper> wwitzel3: are you not testing first?
[20:40] <natefinch> thumper: https://code.launchpad.net/~jameinel/juju-core/replicaset-test-timeout-1290588/+merge/210355
[20:41] <natefinch> thumper: I just approved the MP, we'll see if it merges
[20:41] <wwitzel3> thumper: what do you mean? this is more a workflow and source tree question, than anything. If there is a prefered way for me to handle something like this within bzr.
[20:41] <thumper> wwitzel3: I mean firing up an environment, local and ec2 and actually deploy
[20:41] <hazmat> wwitzel3, i believe that's a reference to actually using the product
[20:42] <wwitzel3> thumper: not for every change no, just been using go test ./...
[20:43] <thumper> wwitzel3: when touching stuff like this where we are changing how real envs install stuff, yes, I'd test that live
[20:45] <wwitzel3> thumper: for this change I bootstrapped and deployed mysql/mediawiki to my local maas
[20:45] <wwitzel3> thumper: I already see what I did wrong though, so never mind :P .. I forgot upload-tools
[21:14] <bodie_> I'm setting up a dev box.  should I go with 12.04 or 13.10?
[22:29] <thumper> wallyworld_: https://code.launchpad.net/~thumper/juju-core/update-golxc-version/+merge/210492 ?
[22:29] <thumper> v small.
[22:29] <thumper> bodie_: I'd use trusty
[22:30] <thumper> but hey, that's just me :)
[22:32] <wwitzel3> thumper: I see you made the update in that branch, thank you
[22:34] <wwitzel3> thumper: actually, that just isn't rebased yet, I need to make the update. Thought actually I am not sure the original update actually resolved the issue since I was testing without using upload-tools
[22:36] <thumper> :)
[22:42] <wallyworld_> thumper: looking
[22:46] <wallyworld_> thumper: shiteveld diff screwed, approced lp mp with a suggestion
[22:51] <bodie_> thanks thumper :)
[22:52] <bodie_> that's what I'm using on my laptop, just not confident it'll serve for dev work.  but if it works, it works