[00:03] <thumper> davecheney: https://github.com/howbazaar/juju/commit/71719716c26571c98bdf6ce3119f0a8c5450cb59
[00:04]  * thumper goes for a run
[00:05] <davecheney> thumper: very nice
[00:05] <davecheney> LGTM
[00:13] <perrito666> wallyworld: https://pastebin.canonical.com/115910/
[00:14] <davecheney> perrito666: that's a paddlin' for using that pastebin
[00:15] <davecheney> now I have to get my ubikey to find out what you wrote
[00:15] <perrito666> sorry chrome completed that one first
[00:16] <bigjools> thumper's name in Spanish means penis?  Why have I not heard this revelation before.
[00:16] <perrito666> bigjools: not really, his last name read in spanish, which is basically read all the letters
[00:17] <bigjools> ah I see
[00:17] <bigjools> still funny
[00:17] <perrito666> bigjools: our fonetics make many english words fun
[00:18] <bigjools> yeah it works in reverse too :)
[00:19] <perrito666> it usually makes a big laugh in my work day by just reading the irc channel with my brain set to spanish
[00:20] <bigjools> heh
[00:24] <perrito666> mmpf the flakiness of this test really annoys me
[00:26] <perrito666> wallyworld: http://pastebin.ubuntu.com/8154484/ seccond pass failed on the testDying test
[00:26] <perrito666> third pass seems to have gone flawless so far and it is beyond failure point
[00:27] <wallyworld> perrito666: the fix definitely is needed, so we can land that and cross our fingers
[00:28] <perrito666> wallyworld: mm I just got a very interesting failure
[00:28] <perrito666> wallyworld:  http://pastebin.ubuntu.com/8154509/
[00:29] <wallyworld> i've  seen those before too
[00:29] <wallyworld> more test badness that happens every so often
[00:30] <perrito666> ok but regardless, the Dying test passed
[00:31] <perrito666> 4th run
[00:31] <wallyworld> good so far, i'll keep looking in case there's more than can be done
[00:37] <perrito666> man I have seen thrillers with less suspense than this test run
[00:41] <perrito666> wallyworld: I added a card for this issue, please make sure to move it to done when you finish later today
[00:41] <wallyworld> perrito666: that wait we added is not enough - the start up does not account for the fact that the machine may be marked as dead after that. i will need to add some more code
[00:41] <wallyworld> ok
[00:42] <perrito666> wallyworld: we could use the channel for more than just a flag
[00:42] <perrito666> wallyworld: ok the last pass re-triggered the other error but the dying error is no longer triggered
[00:43] <perrito666> wallyworld: I do not believe there is a connection so it should be safe to add the wait as we did
[00:43] <wallyworld> it's a bit more complicated - worker startup can fail because a machine is dead, and return an arbitrary error. this case does not trigger the agent to die. we only check for dead machines right at the start and not thereafter
[00:44] <wallyworld> i need to add some logic account for this
[00:45] <perrito666> well my brain just turned into jelly so I will be out of here, I will reassign this to you, I will add a comment with what you just said, ok?
[00:47] <perrito666> wallyworld: ?
[00:47] <wallyworld> perrito666: i'll update the bug. thanks for you help
[00:48] <wallyworld> have a goodevening
[00:48] <perrito666> wallyworld: tx
[00:48] <perrito666> here have the paste to save you some work
[00:48] <perrito666> The wait we added is not enough (using the provided channel) - the start up does not account for the fact that the machine may be marked as dead after that and return an arbitrary error. this case does not trigger the agent to die. we only check for dead machines right at the start and not thereafter.
[00:48] <perrito666> Logic to account for this will be added by Ian who just took over.
[00:56] <davecheney> anyone seen this before ?
[00:56] <davecheney> http://paste.ubuntu.com/8154661/
[00:57] <davecheney> ignore
[00:57] <davecheney> i have local changes
[00:57] <davecheney> and I broke some shit
[01:22] <davecheney> question
[01:22] <davecheney> when was juju ssh changed to always ssh via the bootstrap node ?
[01:23] <axw_> late last year
[01:23] <davecheney> shows how much I know
[01:23] <davecheney> for all providers ?
[01:23] <axw> oh sorry
[01:23] <axw> I misread
[01:24] <axw> can't remember, I think early this year though
[01:24] <axw> yes, all providers (except local)
[01:24] <davecheney> ok
[01:24] <axw> it can be disabled
[01:25] <davecheney> nah, it's ok
[01:25] <davecheney> just hit a stange error message when sshing to a unit
[01:25] <davecheney> tlaking about an internal addrss
[01:33] <davecheney> perrito666: i replied to yor email
[01:33] <davecheney> i think you need to do more to make it clear that action is required from others, and make those others aware that the ball is in their court
[01:44] <perrito666> thank you very much for taking the time davecheney
[01:53] <wallyworld> perrito666: i got a fix up. i experimented with a few approaches, but what's there seems to work https://github.com/juju/juju/pull/612
[02:15] <wallyworld> axw: changes pushed
[02:16] <axw> wallyworld: looking
[02:21] <wallyworld> thanks axw
[02:47] <thumper-otp> wallyworld_: bugger... *os.PathError = &os.PathError{Op:"write", Path:"/mnt/tmp/gocheck-2703387474910584091/5/ssh", Err:0x1c} ("write /mnt/tmp/gocheck-2703387474910584091/5/ssh: no space left on device")
[02:47] <thumper-otp> tests failed
[02:47] <thumper-otp> no disk left
[02:47] <wallyworld_> thumper: rerun
[02:47] <thumper> wallyworld_: is it a dedicated instance?
[02:48] <wallyworld_> i have seen that once before
[02:48] <wallyworld_> it is an instance stated new each time
[02:48] <wallyworld_> not sure why it happens
[02:48] <thumper> hmm... ok
[03:02] <ericsnow> FYI, there's a chance I will have a reviewboard site up for demo tomorrow, hosted in the CI environment :)
[03:09] <wallyworld_> ericsnow: you legend
[03:47] <wallyworld__> axw: could you please take another look at this PR. i had to propagate the ErrDead back to the caller which is something i was trying to get away with not doing https://github.com/juju/juju/pull/612
[03:47] <wallyworld__> but alas it is needed
[03:47] <axw> sure, looking
[03:49] <axw> wallyworld__: bleh, would be nice if we had an IsTerminateAgent predicate that knew about errgo
[03:49] <wallyworld__> yeah. one step at a time :-)
[03:50] <wallyworld__> i just want to get this little fucker landed so we can release 1.20.6
[03:52] <axw> wallyworld__: given that it's "not found or dead", perhaps just use the existing CodeNotFound?
[03:53] <wallyworld__> axw: thought about it, but i think Dead is a distinct error. i think the message in ErrDead() is broken tbh
[03:54] <wallyworld__> i'm 50/50
[03:54] <axw> wallyworld__: what is the error code returned without new mapping?
[03:54] <wallyworld__> ""
[03:54] <axw> heh, ok
[03:54] <wallyworld__> as the error is not recognised
[04:00] <axw> wallyworld__: lgtm
[04:00] <wallyworld__> ty
[04:01] <wallyworld__> i hope it works this time
[04:29] <davecheney> wow, the tests take SOOOOOOOOOOOOO long to run
[04:35]  * thumper sighs
[04:35] <thumper> axw: where are the bootstrap logs written?
[04:35] <thumper> axw: when bootstrapping?
[04:35] <axw> thumper: cloud-init-output.log
[04:35] <axw> /var/log/cloud-init-output.log
[04:36] <axw> $root-dir/cloud-init-output.log for local
[04:36] <thumper> ah, local is what I'm looking for
[04:38] <thumper> axw: I don't suppose you have a handy bunch of tricks to poke around the inside of the mongo db?
[04:38] <axw> thumper: https://github.com/kapilt/juju-dbinspect
[04:38] <axw> other than that, fraid not
[04:39] <thumper> nah, want a bit lower level than that
[04:39] <thumper> thanks anyway
[04:39]  * thumper goes to google
[04:40] <davecheney> thumper: /usr/bin/hd
[04:41] <thumper> hd?
[04:41]  * axw prefers the oscilloscope
[04:41] <thumper> screw you guys
[04:41]  * thumper goes back to googl
[04:42] <davecheney> thumper: echo "1" > /dev/tcp/localhost/17017
[04:58] <axw> davecheney: I think I found why the cmd/juju tests slowed down so much
[04:59] <axw> I made some changes to bootstrap to generate the system-identity sooner. we just need to pregenerate that for tests
[05:04] <davecheney> axw: cool
[05:04] <davecheney> what is the system-identify ?
[05:04] <axw> davecheney: a private key owned by state servers for logging into other machines
[05:08] <axw> davecheney: I might just move it into server side, shouldn't really be there I think. Anyhow, I'm looking into it
[05:09] <davecheney> right
[05:09] <davecheney> i see
[05:09] <davecheney> sheesh
[05:12] <wallyworld__> davecheney: thanks for the syslog info - i had forgotten the reason
[05:13] <davecheney> wallyworld__: syslog is a bit better in Go 1.3, but
[05:13] <davecheney> a. we've standardized on 1.2
[05:13] <davecheney> b. eveyrone has lost confidence in that package
[05:15] <davecheney> axw: related LP 1356806
[05:16] <davecheney> mup: ping
[05:16] <mup> davecheney: I apologize, but I'm pretty strict about only responding to known commands.
[05:16] <davecheney> mup: 1356806
[05:16] <mup> davecheney: In-com-pre-hen-si-ble-ness.
[05:16] <davecheney> #1356806
[05:16] <mup> Bug #1356806: cmd/juju: juju takes 3 seconds to do nothing <juju-core:Triaged> <https://launchpad.net/bugs/1356806>
[05:16] <axw> davecheney: thanks
[05:17] <davecheney> axw: how did you find the problem
[05:17] <axw> davecheney: ah that's a bit different
[05:17] <axw> davecheney: go test -gocheck.vv
[05:17] <davecheney> what does that show over -v ?
[05:17] <axw> gives me timing for SetUpTest
[05:17] <davecheney> ahh
[05:17] <davecheney> then you werelike "wtf is taken 3 seconds ...
[05:18] <davecheney> axw: can you please log an issue for this bug
[05:18] <davecheney> i have a feeling that this will show up on arm and ppc64
[05:18] <davecheney> until fixed
[05:18] <davecheney> as they don't have a fast path for big.Rat
[05:18] <axw> davecheney: will do
[05:37] <thumper> wallyworld__: what is the magic to turn off apt update/upgrade with local?
[05:39] <thumper> wallyworld__: actually more fucked up than that...
[05:39] <thumper> wallyworld__: we are issuing apt-get update/upgrade  on the host machine for the local provider
[05:39] <thumper> wallyworld__: we really shouldn't be...
[05:40] <davecheney> thumper: search your email for a message from katco today
[05:41] <thumper> ah... nada
[05:42] <wallyworld__> thumper: the defaults should have stayed the same
[05:42] <thumper> wallyworld__: they didn't
[05:42] <davecheney> thumper: https://bugs.launchpad.net/bugs/1350493
[05:42] <mup> Bug #1350493: 1.20.x local provider not running apt-get update <charms> <regression> <juju-core:Fix Committed by cox-katherine-e> <https://launchpad.net/bugs/1350493>
[05:42] <davecheney> bottom of that
[05:43] <thumper> davecheney: ta... however the more challenging issue is the apt-get update/upgrade on the host of the local
[05:43] <wallyworld__> davecheney: right, the intent was to keep things how they used to be by default
[05:43] <thumper> i.e. my machine
[05:44] <wallyworld__> thumper: it was supposed to only run any apt commands inside the container once created. so seems like there's a bug there if that's not the case. should be an easy fix
[05:44] <thumper> wallyworld__: I haven't tested a container
[05:44] <wallyworld__> ie yes, it should not be touching host machine
[05:44] <thumper> just bootstrapping local
[05:45]  * thumper nods
[05:45] <thumper> should be easy enough
[05:45] <wallyworld__> yep, will be fixed overnight
[05:45] <thumper> davecheney: any idea what user.Current().Username looks like on windows?
[05:45] <davecheney> thumper: LOCALDOMAIN/admin
[05:45] <thumper> davecheney: particularly wondering about spaces and capitals
[05:45] <davecheney> ^ total guess
[05:46] <davecheney> yes, it can have both
[05:46] <thumper> bugger
[05:46] <davecheney> oh boy
[05:47] <davecheney> just read os/user/lookup_windows.go
[05:47]  * thumper doesn't have the source
[05:48] <davecheney> assume the worse
[05:48] <davecheney> worst
[05:48] <thumper> well, for me that means unicode
[05:48] <thumper> and various bits of punctuation
[05:48] <davecheney> yup, all that is allowed
[05:49] <davecheney> _In_   PLSA_UNICODE_STRING Names,
[05:49] <davecheney> trying to find the msdn docs
[05:49] <davecheney> http://msdn.microsoft.com/en-us/library/windows/desktop/ms721799(v=vs.85).aspx
[05:49] <davecheney> thumper: what were you planning on using that string for ?
[05:50] <thumper> davecheney: the default admin user name, but it has to be squeezed through names.IsValidUser
[05:50] <davecheney> no chance
[05:50] <davecheney> sorry
[05:50] <davecheney> for a start
[05:50] <thumper> ok, so here is the plan :-)
[05:50] <davecheney> windows calls it
[05:50] <davecheney> Adminstrator
[05:51] <davecheney> with a capital A
[05:51] <thumper> grab the username
[05:51] <thumper> if there is a slash, take the last part
[05:51] <thumper> then lower case it
[05:51] <thumper> replace spaces with dashes
[05:51] <thumper> then validate check
[05:51] <thumper> if invalid -> "admin"
[05:51] <thumper> otherwise use it
[05:51] <davecheney> windows usernames are case sensitive
[05:51] <davecheney> Admin != admin
[05:51] <davecheney> unlikely
[05:51] <davecheney> but if you want to do it right
[05:59] <axw> davecheney: ok  	github.com/juju/juju/cmd/juju	155.808s
[05:59] <axw> down from 400-odd
[05:59]  * axw proposes
[05:59] <dimitern> axw, \o/
[06:00] <davecheney> axw: nice one
[06:00] <davecheney> axw: this is anything that embeds jujuconnsuite isn't it ?
[06:01] <axw> davecheney: anything that bootstraps, so yep
[06:02] <davecheney> son of a bitch
[06:29] <davecheney> axw: nice one, this one should merge like a greased pig
[06:30] <wallyworld__> oink
[06:33] <davecheney> axw: ok  github.com/juju/juju/cmd/juju549.275s
[06:34] <davecheney> still sucks in the cloud
[06:34] <axw> ? :(
[06:34] <axw> is that my PR?
[06:34] <axw> nope
[06:34] <wallyworld__> nope, that's mine i think
[06:34] <davecheney> sorry, yes
[06:34] <wallyworld__> mine is running now
[06:34] <davecheney> Building https://github.com/wallyworld/juju.git revision agent-version-on-startup-maste
[07:14] <bodie_> if anyone has any obvious review for https://github.com/juju/juju/pull/617 it would be appreciated while I wait to go over the panic with jcw4
[07:14] <bodie_> thanks all :)
[08:02] <TheMue> morning
[08:09] <mattyw> morning all
[08:16] <dimitern> anyone willing to review a short patch for the critical  https://bugs.launchpad.net/juju-core/+bug/1361374 (along with a few others) ? PTAL https://github.com/juju/juju/pull/618
[08:16] <mup> Bug #1361374: maas provider assumes machine uses dhcp for eth0 <addressability> <maas-provider> <network> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1361374>
[08:19] <TheMue> dimitern: looking
[08:19] <dimitern> TheMue, thanks!
[08:31] <TheMue> dimitern: LGTM, and leads me to postpone my PR for some minutes more. then I’ll integrate your changes into the providers environment capability
[08:35] <dimitern> TheMue, tyvm
[08:54] <gsamfira> morning all
[08:55] <gsamfira> https://github.com/juju/juju/pull/620 <-- if anyone has some spare time, this PR makes wrench build on Windows
[08:58] <TheMue> dimitern: does your latest PR build? I’ve got a problem that our dependencies.tsv looks ill. the kardianos/service uses packages that aren’t listed. so my build fails :/
[08:59] <dimitern> TheMue, it does build - i've first tested that trunk builds as well, and built my branch to test it on MAAS
[09:00] <dimitern> TheMue, run godeps, it should fix it
[09:00] <TheMue> dimitern: I always run godeps first
[09:01] <dimitern> TheMue, did you try go get -u -v bitbucket.org/kardianos/service ?
[09:01] <dimitern> gsamfira, looking
[09:01] <dimitern> gsamfira, morning btw :)
[09:02] <gsamfira> dimitern Thanks :D
[09:02] <TheMue> dimitern: yep, I’ve got a script for it. and I found it in …/pkg/…
[09:02] <TheMue> strange
[09:03] <dimitern> TheMue, the -v and -u flags are important to fetch the package's dependencies, then you run godeps again
[09:05] <dimitern> gsamfira, I'm not sure how's the deal with contributors, but I think new files should have the copyright + license header comments, would that interfere with // +build !windows ? (i.e. does it have to be on the very first line?)
[09:05] <gsamfira> nope...I always forget the copyright *sigh*
[09:05] <gsamfira> lemme add that
[09:05] <TheMue> dimitern: as I said, I *always* do (have a script for it)
[09:06] <dimitern> gsamfira, cheers!
[09:06] <dimitern> TheMue, ok, sorry, I wanted to make sure because I've been bitten by this lots of times :)
[09:07] <TheMue> dimitern: that’s why I created a script :D
[09:08] <dimitern> gsamfira, LGTM with some trivials
[09:09] <TheMue> dimitern: hmm, maybe I found the reason, could be in a conflict of GOROOT and GOPATH *investigating*
[09:10] <gsamfira> dimitern: changes made :). Thanks
[09:10] <dimitern> gsamfira, cheers!
[09:11] <TheMue> no :(
[09:11] <TheMue> dimitern: do you have code.google.com/p/go.exp/fsnotify in your pkg dir?
[09:14] <dimitern> TheMue, nope, just checked
[09:14] <TheMue> dimitern: I got the error message „/home/themue/code/go/src/bitbucket.org/kardianos/service/config/config.go:14:2: cannot find package "code.google.com/p/go.exp/fsnotify" in any of: …“
[09:15] <TheMue> dimitern: same for go.text
[09:15] <TheMue> *grrrr*
[09:16] <dimitern> TheMue, I don't have bitbucket.org/kardianos/service as well
[09:16] <TheMue> dimitern: it is the last line of the tsv
[09:17] <TheMue> dimitern: take a look at github directly
[09:17] <TheMue> dimitern: https://github.com/juju/juju/blob/master/dependencies.tsv
[09:17] <gsamfira> dimitern, TheMue : bitbucket.org/kardianos/service is only needed on Windows to enable jujud.exe as a service
[09:18] <dimitern> gsamfira, right!
[09:18] <gsamfira> TheMue, what errors are you seeing?
[09:19] <TheMue> gsamfira: my run of godeps after a go get of all packages in dep.tsv works
[09:19] <TheMue> gsamfira: but then I wonna do a go test …/.
[09:19] <dimitern> TheMue, so I did "go get -u -v bitbucket.org/kardianos/service", which completed successfully, then I run my run-godeps script to update deps, and finally just to check godeps -u dependencies.tsv - no errors
[09:20] <TheMue> gsamfira: and then I get - below others - the error message shown above
[09:20] <TheMue> dimitern: yep, here too
[09:20] <TheMue> dimitern: but now do a go test for all
[09:20] <dimitern> TheMue, now I'm running go build ./... && go test ./... in the root dir
[09:20] <gsamfira> running now
[09:21] <gsamfira> so far so good
[09:22] <gsamfira> TheMue: can you do a: cd $GOPATH/src/bitbucket.org/kardianos/service && hg log | head
[09:23] <gsamfira> I'm curious if the revision is correct
[09:23] <TheMue> ha! found it, really strange!
[09:23] <TheMue> gsamfira: it’s all fine in the tsv
[09:24] <gsamfira> yup, just wanted to make sure its fine in the repo as well :)
[09:24] <gsamfira> TheMue, what was it?
[09:25] <TheMue> gsamfira, dimitern: dunno why, but I typed „go test …/.“ instead of „go test ./…“. and I this case you get this error, crazy.
[09:25] <gsamfira> ahh :)). I thought it was a typo on irc :D
[09:26] <gsamfira> well then, glad it worked :)
[09:26] <dimitern> TheMue, all tests pass here
[09:27]  * TheMue also has to configure that there’s no more crazy char replacement in his IRC client. nothing to do with this problem, but looks wierd
[09:27] <TheMue> dimitern: see above, strange behavior when using …/. instead of ./…
[09:28] <dimitern> TheMue, ah, it happens :)
[09:29] <TheMue> dimitern: but then I would have expected a different kind of error, really crazy :D
[09:31] <gsamfira> dimitern: can you merge https://github.com/juju/juju/pull/620 if its fine?
[09:32] <dimitern> gsamfira, will look shortly
[09:32] <gsamfira> thanks! :)
[09:32] <TheMue> dimitern: btw, how do you see my three dots …? they always seem to raise a bit up here in my client, drives my crazy
[09:39] <axw> wallyworld_: are you around still?
[09:39] <wallyworld_> hey
[09:40] <axw> hey. I'm changin sync-tools to use the API
[09:40] <axw> seems that --public does not make any sense when we change to no provider storage
[09:40] <axw> do you concur?
[09:40] <wallyworld_> i think --public was sort of obsolete a while back
[09:41] <axw> metadata plugins should take care of that right?
[09:41] <wallyworld_> pretty much. we'll just make sure we check the new implementation satisfies the common workflows
[09:42] <axw> wallyworld_: so I was thinking we could just honour it if the user uses --local-dir
[09:42] <axw> but otherwise it'd be ignored
[09:42] <wallyworld_> that sounds reasonable, bit i'd need to re-read the code to comment for sure
[09:42] <wallyworld_> which i will do
[09:42] <axw> thanks
[09:50] <dimitern> gsamfira, submitted for merging
[09:51] <gsamfira> thank you! :)
[09:51] <dimitern> TheMue, they look different enough - I'm using monospace 11 in xchat
[10:00] <TheMue> dimitern: I found the switch, ... and … ;)
[10:20] <dimitern> TheMue, nice :)
[10:22] <TheMue> dimitern: yeah, sometimes software tries to be more intelligent than you and behaves strange.
[10:22] <TheMue> dimitern: now I'm resolving the merge conflict after your latest change :D
[10:27] <dimitern> TheMue, sweet!
[10:34] <TheMue> dimitern: currently, as a quick change, I'm using your disableNetworkManagement and my RequiresSafeNetworker in a combination. did I get your right that the capability should answer it directly (by taking a look at the configuration)?
[10:35] <dimitern> TheMue, I think the capability should check disableNetworkManagement internally and return true when it is true, before doing other checks
[10:36] <TheMue> dimitern: ok, so have to touch all providers again. :/ at least those are only a few methods :)
[10:38] <dimitern> TheMue, sorry about the fuss :/
[10:38] <TheMue> dimitern: no pro, simply makes sense
[10:41] <TheMue> dimitern: oh, got logical problem now. the capability today tell if a safe or "unsafe" networker shall be used
[10:42] <TheMue> dimitern: but it doesn't tell, if NO networker shall be used
[10:42] <dimitern> TheMue, no, no - there is always a networker running, but if management is disabled we should run a safe one
[10:43] <TheMue> dimitern: ah, here's my mistake, so if disableNetworkManagement is true we return true to run the safe one, got it
[10:44] <dimitern> TheMue, yep
[11:18] <perrito666> good morning everbody
[12:02] <katco`> wallyworld_: brt, mic doesn't seem to be working
[12:02] <wallyworld_> ok
[13:21] <alexisb> perrito666, ping
[13:21] <perrito666> alexisb: pong
[13:21] <perrito666> set, match
[13:21] <alexisb> :)
[13:21] <alexisb> can you jump on the a call to help with a technical question?
[13:21] <perrito666> which call?
[13:22] <alexisb> MAAS call, it is about the windows workload support in juju
[13:22] <alexisb> getting hangout
[13:22] <perrito666> oh, ok, could you giveme the url?
[13:27]  * TheMue sometimes hates unit testing. no need to discuss how valuable it is. but sometime stuff is so interwoven ...
[13:27] <bodie_> TheMue, I always appreciate unit testing and never question its utility ;)
[13:28] <natefinch> morning all
[13:28] <bodie_> hullo natef
[13:28] <bodie_> tab
[13:28] <wwitzel3> hey natefinch
[13:29] <wwitzel3> natefinch: I'm in moonstone, ready when you are
[13:31] <TheMue> bodie_: as I said, no discussion about how much it's worth, only sometimes the effort
[13:32] <perrito666> natefinch: hey wb
[13:37] <alexisb> natefinch, welcome back
[13:50] <bodie_> TheMue, I was just kidding :) but I always realize how much it's worth when something I thought was bulletproof, isn't...
[14:02] <TheMue> bodie_: but in my case it now also leads to a cleaner design using a mockable interface ;)
[14:36] <TheMue> so, the refactored code build, but now I have to change the tests
[15:01] <ericsnow> natefinch, perrito666, wwitzel3: standup?
[15:01] <perrito666> ericsnow: going
[15:01] <aznashwan> Hello, just throwing this out there: has anyone else noticed that we're still using the launchpad.net version of gocheck in all our tests when the repo's been moved to github for like 6 months now?
[15:05] <abentley> We have updated a utopic machine and now the lxcbr0 interface is missing an we can't use the local/lxc provider.  Any ideas?
[15:05] <abentley> The machine is our test slave for utopic.
[15:19] <katco`> hey is anyone from onyx online?
[15:21] <katco`> well maybe someone else can answer this then :)
[15:24] <katco> thumper mentioned that a recent change is causing apt to be run on host machines, not just worker machines, i think when running local. just wanted to see if anyone had some more information on that?
[15:24] <katco> i'm looking at all-machines.log, and my machine's /var/log/apt/history.log, and i'm not seeing evidence that it's being run, but i'm going on the assumption that i'm just not looking where thumper was
[16:03] <hazmat> any folks with juju azure implementation knowlege on hand?
[16:10] <alexisb> mgz_, do you happen to know anything about azure?
[16:11] <mgz_> some, but probably only enough to be dangerous
[16:11] <mgz_> what's the question?
[16:14] <mgz_> hazmat: what's up?
[16:15] <hazmat> mgz_, so we're setting a single affinity group for the entire env.. that seems inappropriate.. afaik the only reason we're doing that is to create a virtual network for private backpane communication between service instances
[16:15] <hazmat> i wanted to confirm that's the only reason we're touching affinity groups
[16:16] <mgz_> yeah, we need all machines able to talk to all other machines, which means they all need to be in the same affinity group, no?
[16:16] <hazmat> because that underlying reason is no longer accurate, ie. regions/locations can be used when creating virtual nets now.
[16:16] <mgz_> current networking work should relax that restriction eventually
[16:16] <hazmat> mgz_, that's the issue, that's not true
[16:16] <hazmat> it may have been at the time, but the apis have been updated
[16:17] <mgz_> okay, sounds like a bug to raise then if we have new azure tools to make it work
[16:17] <mgz_> what should we do instead? we still need some kind of affinity group policy, no?
[16:17] <hazmat> and it impacts how the fabric internally maps instances to fault domains when their in the same affinity group.. ie affinity group tries to say place me on the same rack, where as also want fault domain which is their mapping to az.
[16:17] <hazmat> mgz_, actually we don't
[16:18] <mgz_> and juju can't currently do smart things like put different units of the same service in different groups I think
[16:18] <hazmat> mgz_, we were only using affinity group (on the whole env) for the networking aspect
[16:18] <mgz_> so, just dump the group entirely?
[16:18] <hazmat> mgz_, azure internally will do fault domain placement for us
[16:18] <mgz_> well, that doesn't sound too bad
[16:18] <hazmat> for multiple role instances
[16:22] <mgz_> hazmat: can you file a bug, with some of the details of the new scheme we should use instead?
[16:22] <hazmat> mgz_, sure
[16:22] <mgz_> thanks!
[16:23] <hazmat> mgz_, just want to verify the fault domain mapping on our instances as we create at the moment.. i kinda of wish juju had commands for listing underlying cloud info on instances for admins
[16:24] <mgz_> yeah, we should have an extended status thing really
[16:25] <hazmat> mgz_, for manual provider plugins.. i've started to just have a separate command list-machines with provider specific details
[16:26] <hazmat> a list-machines command in juju might be appropriate for this.. our nested yaml data structs on status are rather hard to interpret visually given their tendancy to scroll off the screen... there's some status work though as part of pain points that may help
[16:54] <bodie_> I have landed and merged the bugfix for intermittent Action related test failures.  is this "released" or "committed"?
[16:54] <bodie_> https://bugs.launchpad.net/juju-core/+bug/1351371
[16:54] <mup> Bug #1351371: state/apiserver/uniter/uniter_test fails TestPreexistingActions when Actions arrive out of order. <actions> <intermittent-failure> <juju-core:Fix Committed by binary132> <https://launchpad.net/bugs/1351371>
[17:06] <perrito666> ppl I am a bit ill Ill go rest a moment and then come back
[17:23] <bodie_> anyone, guidance on the bug status?  I assume it is "committed" because it is not yet in a release version of juju?
[17:23] <bodie_> mgz_, natefinch, alexisb?
[17:25] <natefinch> bodie_: committed
[17:25] <alexisb> one sec bodie_ on a call
[17:25] <natefinch> bodie_: I let sinzui et. al. change it to released
[17:26] <bodie_> okay, cool.  thanks natefinch
[17:29] <alexisb> bodie_, looks like you got your answer
[17:30] <alexisb> thanks natefinch
[18:46] <natefinch> ericsnow: LGTM'd your unrevert
[18:46] <ericsnow> ah, cool
[18:46] <ericsnow> natefinch: thanks
[18:49] <ericsnow> natefinch: FYI, I've filed a bug against the postgresql charm, 1 against reviewboard, and what feels like 100 against the reviewboard charm. :)
[18:49] <ericsnow> natefinch: the charm author has reached out to me. :)
[18:54] <natefinch> ericsnow: awesome... maybe you can help fix up the reviewboard charm
[18:55] <ericsnow> natefinch: it's not on the scale that the author will need much help
[18:56] <ericsnow> natefinch: I did, however, right my first charm (for the OAuth reviewboard extension).
[18:56] <ericsnow> wasn't as hard as I had expected
[18:57] <ericsnow> and writing Python is always like going home :)
[19:22] <natefinch> ericsnow: cool, glad you got to write a charm, and got to exercise those python skills
[20:13] <natefinch> ericsnow: btw, you can upload to your own namespace in the charmstore, with zero overhead or review needed
[20:13] <ericsnow> natefinch: good to know
[20:14] <ericsnow> natefinch: I'll put that on my todo list :)
[20:14] <natefinch> ericsnow: so like juju deploy c:~ericsnow/reviewboard
[20:14] <natefinch> cs:~ericsnow that is
[20:54] <TheMue> so, redesign after merging done, tomorrow morning some polishing. good night all
[21:04] <thumper> katco: morning
[21:04] <katco> thumper: howdy, thumper
[21:04] <thumper> katco: so... here is what I was seeing yesterday...
[21:05] <thumper> was testing the local provider to check some mongo changes I was doing
[21:05] <thumper> juju bootstrap --debug
[21:05] <thumper> for the local provider
[21:05] <katco> thumper: ok
[21:05] <thumper> this showed that the cloud init step was doing an apt-get update/upgrade
[21:05] <thumper> you can see the results in $datadir/cloud-init-log
[21:05] <thumper> or something like that
[21:05] <katco> thumper: on the container? or on your machine?
[21:05] <thumper> it seems that the cloud init script being generated for the local provider on bootstrap is doing the apt dance
[21:06] <thumper> no containers are being created
[21:06] <thumper> just bootstrapping
[21:06] <thumper> which messes with the host machine
[21:06] <katco> thumper: ah yes, ok. i was afraid i misunderstood ian.
[21:06] <thumper> (oh how I'd like to fix that)
[21:06] <thumper> this made bootstrapping the local provider take a lot longer than it needs to
[21:07] <katco> thumper: please forgive my newbness :( doesn't bootstrapping create a container to be the state machine?
[21:07] <thumper> katco: not for the local provider
[21:07] <thumper> it should (in the future)
[21:07] <thumper> but doesn't
[21:07] <thumper> machine 0 for the local provider is the host
[21:07] <katco> thumper: ahhh! there's the insight i was missing.
[21:08] <thumper> the datadir is set to $JUJUHOME/<envname>/
[21:08] <thumper> so for me, with a local called "local"
[21:08] <thumper> the data dir is ~/.juju/local
[21:08] <katco> thumper: ok, so a little background: we wanted the new config settings to trump all, but have sensible defaults
[21:08] <katco> thumper: the defaults for local were to ommit the apt commands only if lxc-clone was on
[21:08]  * thumper nods
[21:09] <natefinch> thumper: can you talk to dpb on canonical's #juju, he has some lxc issues and would like some help, and it's past EOD for me.
[21:09] <thumper> katco: we need to special case the bootstrap node for local
[21:09] <katco> thumper: but it sounds like there's a completely set of code i need to modify to ommit the apt commands from local
[21:09] <katco> thumper: yeah. ok i think ian tried to impart that :p
[21:09]  * thumper nods
[21:09] <katco> thumper: thank you so much, i'll start now. pretty good idea of where the modifications need to be made.
[21:09] <thumper> bootstrap in provider/local/environ.go is already a little special
[21:09] <thumper> kk
[21:09]  * katco laughs
[21:10]  * natefinch has to run
[21:11] <katco> thumper: actually, still a little strange. right now my machine has a nonsensical apt proxy. wouldn't i be seeing failures in /var/log/apt/history.log?
[21:11] <katco> thumper: or is that an incorrect metric?
[21:12] <thumper> umm... apt proxy set where?
[21:13] <katco> thumper: /etc/apt/apt.conf on my machine
[21:13] <katco> thumper: i was trying to use that as a hammer to notify me if _anything_ was awry
[21:13] <thumper> I'm not sure where apt logs problems
[21:14] <thumper> but I would guess /var/log/apt ... something
[21:14] <katco> thumper: (shrugs), i trust you. i'll just make the changes.
[21:16] <katco> arg, my irc client crashed. missed any response after the "i trust you" comment
[21:18] <thumper> katco: I didn't say anything :-)
[21:18] <thumper> I was just basking in the glow of trust
[21:18] <katco> hahaha
[21:48] <katco> thumper: https://github.com/juju/juju/pull/621
[21:49] <thumper> katco: otp now will look shortly
[21:49] <katco> thumper: no problem, just don't want you blocked
[22:17] <wallyworld_> katco: hey, i see you're working on the apt thing. did you want me to look at the other provisioning issue?
[22:17] <katco> wallyworld_: thanks, but i think i almost have that wrapped up
[22:17] <wallyworld_> \o/
[22:18] <katco> wallyworld_: will hop back on that when this PR lands
[22:18] <wallyworld_> sure, just wanted to be sure you weren't blocked
[22:18] <katco> wallyworld_: i'm down to tests that look like they're actual failures due to new harvesting settings, instead of regressiosn
[22:18] <wallyworld_> ok
[22:23] <katco> wallyworld_: you could look at that PR to get it landed faster. that would unblock me :)
[22:24] <wallyworld_> katco: the apt settings one? sure. i thought thumper was so didn't want to double up, but i can. i have a meeting now but will do so straight after
[22:24] <katco> wallyworld_: oh, he'll probably get to it. he's on a call i think.
[22:25] <wallyworld_> ok
[22:25] <katco> wallyworld_: also, is FAIL: upgrade_test.go:324: UpgradeSuite.TestUpgradeStepsHostMachine a transient error?
[22:25] <katco> just got it, hadn't in 2 previous runs >.<
[22:25] <thumper> katco: it certainly shouldn't be
[22:26] <thumper> katco: which failures?
[22:26] <katco> thumper: upgrade_test.go:328:
[22:26] <thumper> katco: which package?
[22:27] <katco> cmd/jujud
[22:27] <perrito666> wallyworld_: great job with the bug yesterday
[22:27] <katco> thumper: running again...
[22:27] <wallyworld_> katco: no, not that i know of
[22:28] <wallyworld_> perrito666: finally got it nailed
[22:28] <wallyworld_> perrito666: one down, 100s more to go :-(
[22:28] <wallyworld_> maybe an exaggeration
[22:29] <perrito666> wallyworld_: well you gotta start somewhere
[22:29] <wallyworld_> perrito666: of course, after that i had to unrevert the erroneous revert of my other branch :-/
[22:29]  * katco throws hands up
[22:29] <katco> it passes
[22:29] <perrito666> wallyworld_: and applied the patch for the fix in master too?
[22:30]  * katco runs the entire suite again...
[22:30] <wallyworld_> perrito666: yup
[22:30] <wallyworld_> katco: welcome to juju testing :-)
[22:30] <katco> wallyworld_: and a warm welcome it is ;)
[22:30] <thumper> that is a terrible test
[22:30] <wallyworld_> "warm"
[22:30] <katco> wallyworld_: almost like being in hell
[22:30] <thumper> and I think mostly unneeded
[22:30] <thumper> I'd like wallyworld_'s opinion too
[22:31] <thumper> I don't believe it should be testing what it is testing
[22:31] <thumper> the upgrade steps should be tested elsewhere
[22:31] <wallyworld_> thumper: otp with alexis, will look soon
[22:31] <thumper> jujud should assert that it is running upgrades, but not that every step has run
[22:31] <thumper> that's just unnecessary
[22:50] <thumper> wallyworld_: I see lots of emails about juju merges accepted, but not rejected nor landed
[22:50] <thumper> wallyworld_: any ideas?
[22:51] <wallyworld_> thumper: will look soon, still otp
[22:51] <alexisb> thumper, quick bugging Ian in our 1x1 ;)
[22:51] <katco> wallyworld_: ian! ian! hey!
[22:51] <thumper> wallyworld_: what ever you do, don't mention that thing to alexisb
[22:52] <wallyworld_> fark off
[22:52] <katco> haha
[22:52]  * katco loves her team
[23:01] <waigani> thumper: standup
[23:07] <katco> thumper: so does this need to be a new concept? update behavior for bootstrap only?
[23:22] <wallyworld_> thumper: yesterday I aborted several of my landings, perhaps that's what you are seeing
[23:23] <thumper> wallyworld_: maybe
[23:23] <waigani> thumper: magic!
[23:23] <thumper> see :)
[23:24] <wallyworld_> thumper: you happy with https://github.com/juju/juju/pull/621 ?
[23:25] <thumper> no
[23:25] <thumper> wallyworld_: looks like the values are being set for the entire environment
[23:25] <thumper> wallyworld_: rather than just the bootstrap node
[23:25] <katco> thumper: wallyworld_: is there an existing concept for settings for a single node or operation?
[23:25]  * thumper takes a quick look
[23:26] <thumper> katco: provider/local/environ.go:139
[23:26] <wallyworld_> thumper: why aren't they needed for the entire environment? all machines which start shoudl have those settings
[23:26] <thumper> here we directly modify the machine config struct for the bootstrap node
[23:27] <wallyworld_> oh wait
[23:27] <thumper> line 167
[23:27] <wallyworld_> i see what you mean
[23:27] <thumper> both line 167/168 should be false, yes?
[23:29] <wallyworld_> thumper: i think that's all that's needed isn't it - just set those 2 to false
[23:29] <thumper> I think so
[23:29] <thumper> to fix this issue anyway
[23:30] <katco> hrm... i see what you mean. so https://github.com/katco-/juju/blob/local-apt-defaults/provider/local/environ.go#L162 would be false
[23:30] <katco> b/c that will only affect the machine config for the state server?
[23:31] <wallyworld_> katco: hmmm. see cloudcfg on line 184
[23:31] <wallyworld_> that also sets the update bools
[23:32] <katco> wallyworld_: right, but it pulls them from the machine config
[23:33] <bodie_> final lynchpin for actions on the unit: https://github.com/juju/juju/pull/617 ready for review (415 and 520 depend on this)
[23:33] <katco> i think setting the machine config to false would be ok, unless you think it should only set the cloud config
[23:33] <wallyworld_> yes, it does, so yes setting mcfg to false should do it
[23:34] <katco> running tests
[23:36] <wallyworld_> you may need a new test for this issue specifically if there's not one there
[23:37] <katco> wallyworld_: https://github.com/juju/juju/pull/621/files#diff-51c33284469e382ba300508359834cc6R210
[23:38] <katco> wallyworld_: hrm. do we want a blanket false? or should we continue to check if the environment settings are set?
[23:39] <katco> wallyworld_: the way it's coded now, even if i set the environment settings to true, the updates/upgrades won't be run
[23:39] <wallyworld_> katco: maybe we should allow the user to override them - otherwise it's just another special case for people to get confused about
[23:39] <wallyworld_> i can't see why they'd want to set them to true
[23:39] <wallyworld_> but they might
[23:40] <katco> wallyworld_: yeah, i agree. if i specifically tell juju to do something, i'd like it to happen :)
[23:40] <wallyworld_> juju world-peace
[23:40] <katco> haha
[23:40] <katco> gotta charm it first
[23:40] <wallyworld_> Error: Juju cannot do that, Hal
[23:49] <katco> wallyworld_: while i'm waiting for tests to finish. remember how you were saying values would be cached on machine objs? if i do an EnsureDead, will a call to Life return the correct value?
[23:50] <katco> wallyworld_: afterward i mean
[23:50] <wallyworld_> katco: should do, let me check
[23:51] <wallyworld_> katco: no, appears not :-( looks like you gotta call Refresh()
[23:51] <katco> wallyworld_: how did you check that so fast?
[23:51] <wallyworld_> state/api/machine/machiner.go
[23:51] <katco> ah
[23:52] <wallyworld_> i knew where to look, bitter experience
[23:52] <katco> someday, i too, will be able to say i have bitter experience.
[23:52] <katco> ;)
[23:52] <wallyworld_> see the EnsureDead() method - doesn't look like it does any update on the struct's life value
[23:53] <wallyworld_> oh, i was bitter before too :-)
[23:53] <katco> haha
[23:53] <wallyworld_> and twisted
[23:53] <katco> it's wally's world and we're all just living in it ;)
[23:53] <wallyworld_> glad you understand
[23:53] <katco> rofl
[23:55] <katco> i think that's one of the bugs right there. b/c i separated the ensuredead from placing it into the dead slice
[23:56] <katco> previously it would ensuredead and then immediately fall into the dead list, despite it's comical assertions that it wasn't yet perished.
[23:56] <katco> *its
[23:58] <wallyworld_> yes, sounds plausible