[00:20]  * thumper off to visit the vet, bbl
[01:08] <davecheney> lucky(~/src/github.com/juju/juju/environmentserver/authentication) % vim authentication.go
[01:08] <davecheney> lucky(~/src/github.com/juju/juju/environmentserver/authentication) %
[01:08] <davecheney> why does this new package have ZERO tests ?!?
[01:08] <davecheney> why is there a whole package for one file
[01:08] <davecheney> and two types !?!
[01:09] <davecheney> no, not two type
[01:09] <davecheney> two functions
[01:09] <rick_h__> davecheney: because it's waiting for you to write the rest of it?
[01:09] <rick_h__> :)
[01:11] <davecheney> rick_h__: i didn't add that
[01:12] <davecheney> me is frustrated with the proliferation of tiny packages
[01:12] <davecheney> ffs people, this isn't java
[01:52] <davecheney> menn0: https://github.com/juju/juju/pull/284
[01:52] <davecheney> small PR for your lunchtime perusal
[01:59] <menn0> davecheney: will look right after this meeting (if it happens)
[02:06] <davecheney> oh shit
[02:06] <davecheney> i was going to take a screenshot of the hangout screen that showed 12:05
[02:06] <davecheney> but the it ticked over to 12:06
[02:06] <davecheney> and it didn't hav the ring to it
[02:07] <davecheney>         info.SetAPICredentials(configstore.APICredentials{
[02:07] <davecheney>                 User:     apiInfo.Tag.Id(),
[02:07] <davecheney>                 Password: apiInfo.Password,
[02:07] <davecheney>         })
[02:07] <davecheney> ohh,
[02:07] <davecheney> here is an intersting one
[02:07] <davecheney> we have a Tag, so "user-dave"
[02:07] <davecheney> but the api credentials being written down will be "dave"
[02:07] <davecheney> so that User field cannot be used to turn back into a tag
[02:07] <thumper> yeah, that is all fucked up
[02:07] <thumper> anyway...
[02:07] <thumper> I've touched that I think
[02:08] <davecheney> where do those credntials go ?
[02:08] <thumper> those are stored in the .jenv file
[02:08] <davecheney> if the thing at the other end is doing
[02:08] <davecheney> names.ParseUserTag
[02:08] <davecheney> that is ok
[02:08] <thumper> it isn't
[02:08] <davecheney> if it's doing
[02:08] <davecheney> names.ParseTag
[02:08] <davecheney> then it's wrong
[02:09] <davecheney> ok, comment added anyway, i'll come back to it after I've fixed the compile errors
[02:09] <thumper> I think it is doing neither
[02:11] <davecheney> thumper:
[02:11] <davecheney>         var environUUID string
[02:11] <davecheney>         if apiInfo.EnvironTag != nil {
[02:11] <davecheney>                 tag, err := names.ParseEnvironTag(apiInfo.Tag)
[02:11] <davecheney>                 if err != nil {
[02:11] <davecheney>                         return err
[02:11] <davecheney>                 }
[02:11] <davecheney>                 environUUID = tag.Id()
[02:11] <davecheney>         }
[02:12] <thumper> yep
[02:12] <davecheney> so, if the environtag _is_ set, then ignore it and use the id of the apiInfo.Tag ...
[02:12] <davecheney> o_O
[02:13] <thumper> ah wat?
[02:13] <thumper> I misread the code
[02:13] <thumper> that is all sorts of fucked up
[02:13] <thumper> pretty sure it should be using EnvironTag ...
[02:15] <davecheney> yup
[02:19] <davecheney> thumper: do you want me to land a quick branch to fix this before doing some more wholescale changes ?
[02:19] <thumper> yeah, I think that would be good
[02:20] <davecheney> ok, two secs
[02:20] <thumper> davecheney: if it makes you feel better, I'm down in the trenches of weird/shitty code too
[02:22] <davecheney> \o/
[02:24] <davecheney> thumper: menn0 https://github.com/juju/juju/pull/285
[02:25] <thumper> davecheney: there are no tests?
[02:25] <davecheney> don't appear to be
[02:25] <thumper> how silly of me... a test would have shown it wasn't working
[02:25] <davecheney> didn't run the whole test suite
[02:25] <davecheney> just go test ./juju/api
[02:25] <thumper> davecheney: is there a quick test that could be written around that?
[02:25] <davecheney> thumper: no idea
[02:26] <davecheney> haven't looked at the tests in that code
[02:26] <thumper> can you take a look?
[02:36] <davecheney> hmm
[02:36] <davecheney> so
[02:36] <davecheney> none of our test fixtures have an environment-uuid: field
[02:39] <davecheney> ok, this is bigger than a quick branch
[02:39] <davecheney> logging a bug
[02:42]  * thumper is fighting side-effects in code being tested elsewhere
[02:42] <davecheney> https://bugs.launchpad.net/juju-core/+bug/1339967
[02:42] <_mup_> Bug #1339967: juju: cacheAPIInfo users the wrong tag when storing the environ UUID <juju-core:New> <https://launchpad.net/bugs/1339967>
[02:42] <davecheney> its on the list
[02:42] <davecheney> i don't want to get distracted
[02:55] <thumper> davecheney: can play.golang.org do github imports?
[02:57] <waigani_> thumper: failed for me, maybe it does certain ones??
[02:57] <davecheney> thumper: no
[02:57] <thumper> failed for me too...
[02:57] <thumper> ok that is why
[02:58] <waigani_> func RunConfigureScript(script string, params ConfigureParams) error {
[02:58] <waigani_> 	logger.Debugf("Running script on %s: %s", params.Host, script)
[02:58] <waigani_> 	client := params.Client
[02:58] <waigani_> 	if client == nil {
[02:58] <waigani_> 		client = ssh.DefaultClient
[02:58] <waigani_> 	}
[02:58] <waigani_> 	cmd := ssh.Command(params.Host, []string{"sudo", "/bin/bash"}, nil)
[02:58] <waigani_> 	cmd.Stdin = strings.NewReader(script)
[02:58] <waigani_> 	cmd.Stderr = params.ProgressWriter
[02:58] <waigani_> 	return cmd.Run()
[02:58] <waigani_> }
[02:58] <waigani_> client is not being used at all ?!?!
[02:59] <davecheney> looks that way
[03:00] <waigani_> hmph - I'll leave a question for the reviewer
[03:00] <davecheney> does that code even compile ?
[03:00] <waigani_> cloudinit/sshinit/configure.go:52
[03:01] <waigani_> yep, I have not touched it
[03:01] <waigani_> davecheney: ^
[03:01] <davecheney> it's cos of the check
[03:01] <davecheney> the if on line 51
[03:02] <waigani_> yep
[03:02] <davecheney> http://play.golang.org/p/m4Z-kfxN3w
[03:02] <davecheney> oh well
[03:02] <thumper> why oh why are so many of our tests so shit?
[03:03] <davecheney> thumper: you know that 383,000 lines of code ?
[03:03] <davecheney> that's not a number i'm particularly proud of
[03:03]  * thumper smirks
[03:05] <waigani_> I'm assuming they meant client.Command(... not ssh.Command
[03:06] <davecheney> waigani_: yes
[03:06] <davecheney> log a bug
[03:07] <waigani_> davecheney: I actually need to fix it for my branch - need to manually provision with a given key
[03:08] <waigani_> davecheney: should I still associate a bug with it and address it in my PR?
[03:15] <davecheney> waigani_: if you're not going to fix it staight away
[03:15] <davecheney> log a bug
[03:15] <davecheney> so when you are on leave next week
[03:15] <davecheney> it doesn't get lost
[03:35] <menn0> woot. I think I've reviewed everything that needs reviewing.
[03:36] <menn0> I'll keep an eye on the PR queue but ping me if there's anything that needs urgent review.
[03:36] <thumper> omg...
[03:36] <thumper> I found a test that tests something that can never happen...
[03:36] <thumper> effectively it goes like this:
[03:36] <thumper> look for the api end points
[03:36] <thumper> make sure there are no addresses
[03:36] <thumper> if there are no addresses, connect to the api to find the addresses
[03:36] <thumper> return addresses
[03:37] <thumper> yay
[03:37]  * thumper waves his hand
[03:37] <thumper> magic
[03:37] <thumper> juju magic
[03:41]  * thumper sighs
[03:41] <menn0> thumper: the test does that and passes?
[03:42] <thumper> menn0: well it mocks out the actual connection
[03:42] <thumper> to return values
[03:43] <menn0> right. so it's an unnecessary test.
[03:45] <thumper> yup
[03:46] <thumper> here is a good error message: logger.Warningf("cannot failed to cache API addresses: %v", localerr)
[03:46] <thumper> double negative, so it worked, right?
[03:51] <menn0> 8-)
[03:56] <thumper> WT actual F?
[03:56]  * thumper sighs
[03:56]  * thumper holds in the rage and turns a little green
[03:57] <thumper> why, oh why would the environment uuid change on an api connection?
[03:57] <thumper> perhaps to save it?
[03:57] <thumper> when it wasn't before?
[03:57] <thumper> that is the only consideration I can think of
[03:59] <thumper> davecheney: if I have a function that is package private, but I also export the func in export_test.go using the BigName = smallName method
[03:59] <thumper> davecheney: but the function takes an arg that is an unexported interface
[03:59] <thumper> davecheney: is go going to complain?
[03:59] <thumper> or magically work?
[03:59] <thumper> as long as what I pass in matches?
[04:22] <thumper> hmm... unnecessary test is not entirely unnecessary
[04:22] <thumper> there are other assumptions built int
[04:22] <thumper> in
[04:42] <menn0> thumper: while working on the schema migrations doc I think I've found a bug in the current upgrade mechanics
[04:42] <thumper> oh?
[04:42] <menn0> thumper: line 817 cmd/jujud/machine.go
[04:43] <thumper> there
[04:43] <menn0> a variable holding an error is carefully created but is never used
[04:43] <menn0> and there's no tests that look for that error
[04:43] <menn0> so if upgrades fail we silently ignore the failure and everything keeps going as if the upgrade was successful
[04:44] <thumper> heh
[04:44] <thumper> oops
[04:44] <thumper> we should probably fix that
[04:45] <menn0> I think the last return in runUpgrades should be "return err" not "return nil"
[04:45] <thumper> surely there is a test...
[04:45] <thumper> this was wallyworld_, so there should be a test
[04:45] <menn0> I searched for "cannot perform upgrade" in the entire tree and it's only mentioned in that function
[04:47] <thumper> hmm
[04:47] <thumper> write a failing test :)
[04:47] <wallyworld_> thumper: menn0: it wasn't me
[04:47] <thumper> one where the step always fails
[04:47] <thumper> and check
[04:47] <wallyworld_> it was roger :-P
[04:47] <wallyworld_> look at annotate :-)
[04:47] <menn0> will do. I know this bit of the code quite well now.
[04:48] <thumper> also... should probably look at the upgrade error before the "failed to update agent version error"
[04:48] <wallyworld_> i suspect there hsould have been a baned return value
[04:48] <wallyworld_> named
[04:49] <menn0> wallyworld_: yep understood
[04:49] <wallyworld_> :-)
[04:49] <menn0> I think it might be clearer without a named return anyway
[04:51] <menn0> wallyworld_: what is currently the desired behaviour if a upgrade steps fail? it's 50/50 whether it's better to downgrade or pressing on with the new version depending on which upgrade steps have already run.
[04:51] <menn0> soon we will be able to rollback using the backup, but what do we expect right now?
[04:53] <wallyworld_> menn0: hmmm. we haven't really supported rollback till now. rollback is more than db, includes config also etc. we don't really handle upgrade errors very well.
[04:53] <wallyworld_> hard problem
[04:53] <menn0> wallyworld_: right and I'm trying to make that situation better.
[04:53] <menn0> wallyworld_: but given current limitations what do we do?
[04:53] <wallyworld_> error out and then the agent restarts
[04:53] <menn0> wallyworld_: or what /should/ we do is probably the better question
[04:54] <wallyworld_> try and recover
[04:54]  * thumper is pulling gently on the end of a piece of string, but is just getting a big knot every time
[04:54] <wallyworld_> and restart the old agent
[04:55] <menn0> wallyworld_: ok. that seems about the best we can do.
[04:55] <wallyworld_> yeah
[04:55] <menn0> the old agent may not work because of changes made by upgrade steps for the next version but we can't do much better
[04:55] <wallyworld_> we can try and rollback the file changes
[04:55] <wallyworld_> but that may not work either
[04:55] <menn0> soon we will be recovering from the backup which has both the database and configuration files
[04:56] <wallyworld_> the thought was, if it fails, it's time to call juju support
[04:56] <menn0> got it
[04:56] <wallyworld_> great, look forward to that
[04:58] <menn0> wallyworld_: it was definitely rog's change... I just had a look and I can see exactly what happened.
[04:58] <wallyworld_> \o/
[04:59]  * wallyworld_ makes mistakes too, but sometimes needs to defend his honour :-)
[04:59] <wallyworld_> especially since thumper implied there should have been a test :-)
[04:59] <thumper> wallyworld_: that is because you always supply tests for your work
[04:59] <menn0> although the lack of pre-existing tests for that error condition probably didn't help when rog refactored that code...
[04:59] <wallyworld_> yes :-)
[04:59] <menn0> :-p
[05:00] <wallyworld_> well, i didn't write the original either
[05:00] <menn0> just teasing
[05:00] <wallyworld_> the jujud upgrade stuff is separate from the upgrade steps stuff
[05:00] <wallyworld_> :-P
[05:00]  * menn0 rolls up his sleeves
[05:00]  * wallyworld_ takes the bait
[05:00] <menn0> ;-)
[05:00]  * wallyworld_ needs sleep, later
[05:40] <thumper> success... just one failing test to fix
[05:40]  * thumper is done for now
[05:40] <thumper> meetings later
[05:40] <thumper> night all
[05:57] <ChrisW1> menn0: someone refactored untested code? tsk tsk
[05:58] <menn0> ChrisW1: indeed :)
[06:04] <davecheney> thumper: re that test, http://static.comicvine.com/uploads/original/11111/111119363/3792894-7922452111-tumbl.gif
[06:05] <davecheney> it won't complain, but you won't be able to construct a value to pass to that function
[06:05] <davecheney> however, if you have someone elses' value, that will work
[06:06] <davecheney> menn0: re named return, hold that thought
[06:06] <davecheney> it will be a good example for waigani
[06:07] <davecheney> menn0: chrisw1, http://dave.cheney.net/2013/11/14/more-simple-test-coverage-in-go-1-2
[06:07] <davecheney> may be useful for figuring out which footguns are lacking their protective covers
[06:08] <menn0> davecheney: I'm not sure if this is the best sample for discussing named returns
[06:08] <davecheney> menn0: what was the bug you found before ?
[06:08] <menn0> the code is hairy
[06:09] <menn0> not really about named returns
[06:09] <davecheney> :/
[06:09] <menn0> thumper or wallyworld were theorising that perhaps someone intended there to be named returns but there wasn't
[06:09] <menn0> at any rate, no named returns are being used
[06:10] <menn0> the bug is about an error not being returned
[06:10] <davecheney> ok
[06:10] <menn0> a line that says "return nil" when it should say "return err" (well actually it's more complex than that but that's the core of it)
[06:10]  * davecheney moves on
[06:10] <davecheney> :~
[07:18] <menn0> frustrated email sent to juju-dev
[07:18] <menn0> I'm done for this week.
[07:18] <menn0> Back on Monday.
[08:09] <TheMue> morning
[08:23] <urulama> i've just filed bug 1340077 (https://bugs.launchpad.net/juju-core/+bug/1340077) ... didn't find similar one, but maybe it already exists
[08:23] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:23] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:24] <davecheney> 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077 1340077
[08:24] <davecheney> #1340077
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <davecheney> i wonder if mup is dumb enough to fall for that
[08:25] <davecheney> #1340077 #1340077 #1340077 #1340077 #1340077 #1340077 #1340077 #1340077 #1340077
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <_mup_> Bug #1340077: if "default" is named to undefined env, the parsing fails <juju-core:New> <https://launchpad.net/bugs/1340077>
[08:25] <davecheney> and the answer is, yes
[08:25] <urulama> QED ;)
[08:25]  * davecheney waves to urulama 
[08:25] <davecheney> welcome to canonical
[08:25] <urulama> thanks
[08:27] <urulama> oh, australia, good evening then
[08:28] <davecheney> o/
[08:28] <davecheney> i'm representing for the southen himsphere tonight
[08:32]  * TheMue waves as antipode
[09:03] <jam> urulama: welcome. So how does one intend to pronounce "urulama" ? My first instinct is to read it as "you're a llama", but the intent could be something different
[09:04] <urulama> jam: :D :D
[09:05] <urulama> jam: never thought about that ... it's an old nick, so old that i don't thing about it, but maybe it is time to change it
[09:06] <urulama> jam: "ooroo"+"llama" would sound as we read it
[09:06] <jam> urulama: strong l or a y or a j sound ?
[09:06] <urulama> strong L
[09:22] <TheMue> jam: urulama: maybe it’s the right time to have nicks in phonetics (thinking of international teams)
[09:22] <urulama> TheMue: or in asciiart :D
[09:24] <TheMue> urulama: ;)
[09:28] <TheMue> so, mine is ðə mjuː
[09:32] <urulama> it's probably a known bug that autocomplet for debug-hooks in terminal returns charm/1 as charm is on machine 1, but hooks are connected only when "juju debug-hooks charm/0" is executed?
[09:34] <urulama> on a amazon or manual env, not on local
[10:15] <dimitern> tasdomas`, I added some review comments to your ports PR
[10:38] <jam> urulama: I haven't heard of it, so feel free to report a bug about autocomplete, as the first unit of a service is always 0, it shouldn't depend what machine it is on.
[10:43] <TheMue> so, https://github.com/juju/juju/pull/281 is back in for review
[10:45] <jam> TheMue: dimitern vladk|offline standup?
[10:53] <urulama> one more bug 1340133
[10:53] <_mup_> Bug #1340133: debug-hooks don't work in manual env <juju-core:New> <https://launchpad.net/bugs/1340133>
[11:02] <jam> urulama: whenever I read your name my first response is "nu-uh, *you're* a llama" :)
[11:02] <uru_> damn, taken
[11:03] <uru-urnotallama> jam: better? :D
[11:03] <TheMue> *rofl*
[11:04] <jam> uru-urnotallama: :)
[11:11] <jam> dimitern: so you're gone from tomorrow for 2 weeks/
[11:11] <jam> ah, that's next week
[11:11] <dimitern> jam, yep, next week
[11:31] <tasdomas`> dimitern, thanks
[12:31]  * dimitern needs to step out now, bbl
[12:44] <tasdomas> are pull requests for packages like github.com/juju/names managed by a landing bot or do I just merge them myself (having received an LGTM)
[12:44] <tasdomas> ?
[12:44] <perrito666> morning
[12:45] <TheMue> perrito666: morning
[12:45] <TheMue> perrito666: we’ll see on Sunday, ha? :D
[12:45] <perrito666> TheMue: I return home on sunday, I will most likely sleep trough the game
[12:46] <TheMue> perrito666: hey, you cannot do that, you’ll see  how our team beats yours :P
[12:48] <perrito666> I care as much for football as I do for ... I think there is nothing I care that little about :p
[12:50] <TheMue> perrito666: hehe, in that case
[13:37] <bodie_> morning all
[13:39] <mgz> bodie_: hey
[13:41] <davecheney> mbruzek: hey
[13:41] <mbruzek> davecheney, hello
[13:41] <davecheney> mbruzek: did you see my update on taht issue
[13:42] <davecheney> do you have the dmesg from that system
[13:42] <mbruzek> yes I uploaded dmesg
[13:42]  * davecheney checks email
[13:42] <davecheney> hmm, nup
[13:42] <davecheney> nothing
[13:43] <mbruzek> https://bugs.launchpad.net/ubuntu/+source/gccgo-4.9/+bug/1304754/comments/35
[13:44] <_mup_> Bug #1304754: gccgo has issues when page size is not 4kB <ppc64el> <trusty> <gcc:Fix Released> <gcc-4.9 (Ubuntu):Fix Released> <gccgo-4.9 (Ubuntu):Invalid> <gcc-4.9 (Ubuntu Trusty):Invalid> <gccgo-4.9 (Ubuntu Trusty):Fix Committed by doko> <gcc-4.9 (Ubuntu Utopic):Fix Released> <gccgo-4.9 (Ubuntu Utopic):Invalid> <https://launchpad.net/bugs/1304754>
[13:44] <mbruzek> davecheney, ^
[13:45] <davecheney> mbruzek: it's empty
[13:45] <mbruzek> davecheney, Sorry take the comments/35 off
[13:46] <mbruzek> the bug was updated with my dmesg_output.txt  I thought I would be clever by showing you on which comment, but I left no messages on file upload.
[13:46] <davecheney> mbruzek: thanks
[13:46] <davecheney> ok, so it's not the usual issue
[13:46] <davecheney> dmesg shows no issue
[13:58] <TheMue> wife bought strawberry cake, daughter made a tea - a very good working environment
[15:20]  * perrito666 finds another race
[15:22] <wallyworld_> axw: if you want a break from mongo fun https://github.com/juju/juju/pull/288
[15:26] <katco> AWS question: does anyone know if there's any documentation on what version of signature each region supports?
[15:28] <natefinch> katco: not sure what you mean version of signature
[15:29] <katco> yeah, sorry: http://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html
[15:29] <katco> they support v2, 3, and 4
[15:29] <katco> and i'm trying to introduce support for 4; turns out it's important to know which region supports which
[15:42] <wallyworld_> sinzui: \o/
[15:43] <natefinch> katco: man, that is a terrible name for ... well anything.
[15:43] <natefinch> wallyworld_: btw, A/C people still not here :/  Supposed to be here between 10 and noon, so the clock is ticking
[15:43] <katco> natefinch: mm? what's a terrible name?
[15:44] <wallyworld_> natefinch: np. we'll try not to eat *all* the kunch
[15:44] <wallyworld_> lunch
[15:44] <natefinch> katco: "SIgnature"
[15:44] <katco> natefinch: ah
[15:44] <katco> natefinch: context increase IQ by 100% ;)
[15:45] <perrito666> natefinch: so much for "they usually come here first"
[15:46] <natefinch> perrito666: Usually they end up coming early.  I guess they found out I'm not actually supposed to be working from home today, so decided to come late
[15:46] <perrito666> natefinch: sounds possible
[15:46] <natefinch> There have been a couple times they have simply not shown up.  But I called at 11 to make sure they hadn't just left me off the list this time.
[15:48] <sinzui> wallyworld_, the 1.20.1 final test run and the 1.20.2 first test run were the two best runs CI has seen in 6 weeks. In both cases every test passed the first try. The entire run was less than 2 hour each
[15:48] <wallyworld_> wow, awesome
[15:59] <jcw4> is there a juju / charm acolyte who might be able to help breze441 in #juju ?
[15:59] <jcw4> I tried to prime the pump a bit since his question was vague, but I think there's enough detail now that someone who knows juju/charms better may be able to help with?
[16:05] <natefinch> katco, axw: btw, I pinged niemeyer about moving goamz to github, since some Go people had been asking about which version they should use - launchpad's or the dozens of copies on github.
[16:14] <alexisb> sinzui, good stuff on 1.20.1, thanks for getting it out there!
[16:15] <sinzui> thank you alexisb
[16:32] <perrito666> natefinch: got ac?
[16:35] <axw> natefinch: thanks, I think that'd be a good idea.
[16:37] <katco> natefinch: +1, ty
[16:50] <natefinch> perrito666: they're here, but it's not fixed yet
[16:50] <perrito666> natefinch: well its something
[16:54] <natefinch> perrito666: yeah, but I fear the person they sent is not their most competent at diagnosing problems.  They have like 3 really good technicians and a bunch of flunkies that are not that great
[17:04]  * perrito666 wonders if we cannot fix that, there are like 8 of us here
[17:12] <voidspace> rogpeppe: ping
[17:12] <voidspace> rogpeppe: are you around?
[17:12] <rogpeppe> voidspace: hiya
[17:13] <rogpeppe> voidspace: that i am
[17:13] <voidspace> rogpeppe: hey Roger, hi
[17:13] <voidspace> I'm in Lexington
[17:13] <rogpeppe> voidspace: cool
[17:13] <voidspace> rogpeppe: I have a question about HA
[17:13] <rogpeppe> voidspace: fire away
[17:14] <voidspace> rogpeppe: should all writes go to mongo master - and does that mean that only the machine hosting the mongo primary should do writes, or do the other state servers connect remotely to the primary?
[17:14] <voidspace> or does it mean something else
[17:14] <voidspace> what I'm seeing, which surprised me, is that after "ensure-availability" the machine with JobManageEnviron is not the Primary mongo
[17:14] <rogpeppe> voidspace: if you connect to a mongo secondary, it will automatically make a connection to the primary and send writes there
[17:14] <voidspace> cool
[17:14] <voidspace> so we don't need to worry about that
[17:15] <rogpeppe> voidspace: after ensure-availability, there should be 3 machines with JobManageEnviron
[17:15] <voidspace> they should all have JobManageEnviron, ok
[17:15] <rogpeppe> voidspace: and the choice of primary is entirely up to mongo
[17:15] <voidspace> hmmm... my machine 1 only listed JobHostUnits in its agents.conf
[17:16] <voidspace> rogpeppe: I'm looking at the behaviour of HA when mongo dies but juju itself remains running
[17:16] <rogpeppe> voidspace: when a majority of replicas die?
[17:16] <voidspace> no, just when a single one dies
[17:16] <rogpeppe> voidspace: it *should* just carry on working
[17:17] <rogpeppe> voidspace: although there will be some churn
[17:17] <voidspace> right, but the now "effectively dead" machine is still listed as a valid apiserver
[17:17] <voidspace> when in fact it is screwed
[17:17] <rogpeppe> voidspace: api servers will restart, clients will also need to reconnect
[17:17] <voidspace> but things do still work
[17:17] <voidspace> I'm trying to determine what doesn't work and what we need to fix
[17:18] <voidspace> so yes, api servers will need to restart - but it doesn't look like they do
[17:18] <voidspace> but it's only a minor issue I think
[17:19] <voidspace> the replicaset configuration still lists the dead machine as in the replicaset
[17:20] <voidspace> (the mongo rs.conf() that is)
[17:23] <rogpeppe> voidspace: the dead machine will still remain in the replicaset until you run ensure-availability again
[17:23] <voidspace> right
[17:24] <voidspace> rogpeppe: when you run ensure-availability the first time, and mongo picks a master, will the singular workers stop running on machine-0 and start running on the master (assuming machine-0 is no longer the master)?
[17:24] <rogpeppe> voidspace: yes, they should do
[17:24] <voidspace> rogpeppe: ok, great
[17:26] <natefinch> well fuck, A/C guys say the $800 worth of refrigerant they put in the system is gone and we need a new system.  Fantastic.
[17:26] <voidspace> natefinch: ouch :-/
[17:26] <voidspace> :-(
[17:27] <natefinch> that was like 2 months ago they put that in, too.  Put in some "leak stop" stuff too.  Getting a second opinion in the morning, but... I think it's new A/C time... which means like $8,000
[17:27] <natefinch> anyway, coming into the office
[17:27] <perrito666> natefinch: f*** shouldn't they give you some refund on that? I mean they added refrigerant when they shouldn't
[17:27] <wallyworld_> natefinch: and wwitzel3 ate all the lunch
[17:27] <natefinch> that's ok
[17:27] <natefinch> I had cake for lunch
[17:29] <perrito666> uh, can we have cake?
[17:30] <voidspace> rogpeppe: my machine-1 agents.conf only lists JobHostUnits under jobs, whereas as machine-0 (my current master) lists JobManageEnviron too
[17:30] <voidspace> *agent.conf (singular)
[17:30] <rogpeppe> voidspace: and machine 1 was created by ensure-availability?
[17:30] <voidspace> yep
[17:31] <voidspace> it also lists three api addresses when there are now only two state servers
[17:32] <voidspace> and machine-2 agent.conf - which *was* master  - also only lists JobHostUnits
[17:32] <rogpeppe> voidspace: i don't believe that machine was created without JobManageEnviron
[17:33] <rogpeppe> voidspace: what's the output of juju status?
[17:34] <voidspace> rogpeppe: http://paste.ubuntu.com/7776326/
[17:35] <rogpeppe> voidspace: i see that all of machines 0, 1 and 2 are voting
[17:35] <rogpeppe> voidspace: that means that they're part of the intended replica set
[17:35] <voidspace> rogpeppe: but agent state of 2 is down
[17:35] <voidspace> I took down mongo first
[17:35] <voidspace> agent.conf on the other machines didn't change
[17:35] <voidspace> I took down jujud as well
[17:35] <rogpeppe> voidspace: sure, you can be down and still have a vote
[17:35] <voidspace> still no change (that I could see)
[17:36] <voidspace> but it is also still listed as a valid api server
[17:36] <voidspace> even though it is down
[17:36] <voidspace> but the master change worked fine
[17:37] <rogpeppe> voidspace: all those machines definitely have JobManageEnviron, BTW
[17:37] <voidspace> not listed in agent.conf they don't :-)
[17:37] <voidspace> but I believe you
[17:38] <voidspace> so it's a bit odd
[17:39] <rogpeppe> voidspace: for my proof, see cmd/juju/status.go:323
[17:39] <rogpeppe> voidspace: it's odd that that's not in agent.conf though
[17:39] <rogpeppe> voidspace: that sounds like some kind of bug
[17:40] <voidspace> rogpeppe: http://paste.ubuntu.com/7776354/
[17:40] <voidspace> rogpeppe: machine 1 is the same
[17:40] <voidspace> machine-0 also lists JobManageEnviron
[17:41] <voidspace> rogpeppe: ok, so it's an oddity (probably a bug) but not significant
[17:41] <voidspace> rogpeppe: thanks
[17:41] <rogpeppe> voidspace: well, it may well be significant
[17:41] <voidspace> hah, ah
[17:41] <voidspace> ok
[17:47] <voidspace> if you take down the mongo on the master then the master does switch, but jujud carries on running on the "old master"
[17:50] <rogpeppe> voidspace: jujud will always continue running
[17:50] <rogpeppe> voidspace: it runs on every machine
[17:51] <voidspace> rogpeppe: what would you expect a juju that can't connect to mongo to do?
[17:51] <rogpeppe> voidspace: BTW, AFAICS the Jobs in the agent config isn't used at all
[17:51] <voidspace> rogpeppe: right
[17:51] <voidspace> good
[17:51] <voidspace> rogpeppe: I'm still wondering what writes it out and why it's wrong, but I can look for that
[17:51] <rogpeppe> voidspace: i'd expect a juju that can't connect to mongo to sit around trying to connect to mongo
[17:52] <voidspace> rogpeppe: hah, ok :-)
[17:55] <voidspace> rogpeppe: I think juju behaves fine when we kill mongo
[17:55] <rogpeppe> voidspace: good!
[17:55] <voidspace> it doesn't rewrite agent.conf in the way perrito666 and I thought it should
[17:55] <voidspace> but I don't think that's a problem
[17:55] <rogpeppe> voidspace: nice to know that something works :-)
[17:56] <voidspace> the machine log shows it stopping all the things it should I believe
[17:56] <voidspace> hah
[17:56] <voidspace> indeed :-)
[17:56] <voidspace> so I'm going to close that bug....
[17:58] <rogpeppe> voidspace: ha, i've found the cause of the bad Jobs
[17:58] <rogpeppe> voidspace: i think
[17:58] <rogpeppe> voidspace: in environs.NewMachineConfig
[17:58] <perrito666> rogpeppe: I am pretty sure that I can fit an apple joke in there
[17:58] <rogpeppe> voidspace: the Jobs are always set to JobHostUnits
[17:58] <rogpeppe> perrito666: arf arf
[17:59]  * rogpeppe actually doesn't laugh, because a reference to a joke is not the same as the joke itself
[17:59] <rogpeppe> :-)
[17:59] <voidspace> hah
[18:00] <perrito666> rogpeppe: fine *(rogpeppe: I am pretty sure that I can fit an apple joke in there)
[18:00]  * rogpeppe is still waiting for a joke
[18:00] <voidspace> rogpeppe: so the machine actually has the ManageEnviron job, but we assume that a new machine only has host units (which was the case before HA) and so that's what we put in MachineConfig
[18:00] <rogpeppe> voidspace: yup
[18:00] <voidspace> rogpeppe: you just have to dereference it yourself
[18:01] <voidspace> rogpeppe: could this be a potential problem? (not the apple joke)
[18:01] <voidspace> rogpeppe: let me hedge my bets a bit more
[18:01] <rogpeppe> voidspace: currently no
[18:01] <voidspace> would it be fair to say that it's reasonable to assume that perhaps this could be a potential problem, at least in theory
[18:01] <rogpeppe> voidspace: the plan was always to allow a machine to change its jobs
[18:01] <voidspace> ok
[18:02] <rogpeppe> voidspace: so a machine would populate its own machine config's Jobs field
[18:02] <perrito666> rogpeppe: a skelton enters a bar and he says: bartender, please give me a whisky and a mop
[18:02] <voidspace> I'd tell you a udp joke, but you wouldn't get it
[18:03]  * rogpeppe laughs at both of those
[18:03] <rogpeppe> although i'd heard the udp one before
[18:03] <voidspace> I know another udp joke, but I can't tell that one either - it's a bit out of order
[18:03] <voidspace> yeah, old
[18:03] <rogpeppe> voidspace: pm me :-)
[18:03] <voidspace> rogpeppe: no, that was the joke...
[18:04] <rogpeppe> oh sod
[18:04] <rogpeppe> :-)
[18:04]  * rogpeppe lols a little more
[18:57] <bodie_> I'm really excited that Elon Musk donated $1 million to the new Tesla museum in NY
[18:58] <bodie_> I sure hope they take things far
[19:08] <urulama> can juju-test be run with a parameter to .test file?
[20:11] <mgz> voidspace: https://bugs.launchpad.net/juju-core/+bug/1307434
[20:11] <_mup_> Bug #1307434: talking to mongo can fail with "TCP i/o timeout" <cloud-installer> <landscape> <performance> <reliability> <juju-core:Triaged> <https://launchpad.net/bugs/1307434>
[20:17] <stokachu> anyoen know if the ServiceDeploy api call takes 'lxc:1' as its ToMachineSpec? I can't seem to get it to work
[20:17] <stokachu> or do i have to add machine first
[20:26] <natefinch> stokachu: juju help deploy will give you the format.   What are you trying to get it to do?
[20:27] <stokachu> deploy to an lxc container on machine 1
[20:28] <natefinch> stokachu: before machine 1 exists, I take it?
[20:28] <stokachu> natefinch, no machine 1 exists
[20:30] <natefinch> stokachu: oh, hmm. lxc:1 should work....
[20:31] <stokachu> is the param syntax still {'ToMachineSpec': 'lxc:1'}
[20:33] <natefinch> stokachu: yeah - https://godoc.org/github.com/juju/juju/juju#DeployServiceParams
[20:33] <stokachu> hmm ok i must be doing something wrong with the api call
[20:36] <rogpeppe> g'night all
[20:46] <stokachu> natefinch, if you don't define a NumUnits it just deploys the charm but never attaches itself to a machine
[20:46] <stokachu> shouldnt that give us an error or some indication in the json response?
[20:48] <natefinch> yeah, it's a little wacky since numunits would default to 0, which is not really a valid value in any sense of the words
[20:49] <natefinch> it should probably complain, yeah
[20:49] <natefinch> or default to 1 for numunits < 1
[20:49] <stokachu> yea
[20:50] <stokachu> took me awhile to figure out why the ServiceDeploy api call wasn't associating a machine
[20:55] <thumper> wallyworld_: sorry about missing the resources meeting, but 7am meetings after my late night lead ones isn't a good time
[20:55] <thumper> was too out to it
[20:56] <wallyworld_> thumper: np, we didn't need you anyway :-P
[20:56] <thumper> good
[20:56] <wallyworld_> thumper: i can ping you a bit later and fill you in
[20:57] <thumper> sure
[21:00] <natefinch> stokachu: the CLI stops you from using num units < 1.. the api should, too
[21:00] <stokachu> if i dont define num units it'll just deploy the service with no machine
[21:02] <natefinch> stokachu: yeah, that's a bug.  We haven't really put a lot of effort into making the API foolproof, unfortunately.
[21:02] <stokachu> ill file a bug for it to track then
[21:03] <perrito666> natefinch: that should blow at a lower level
[21:03] <natefinch> stokachu: thanks
[21:04] <perrito666> natefinch: sounds like something that we will never want to allow so making that check should not happen in the borders
[21:04] <perrito666> s/borders/edges
[21:05] <natefinch> perrito666: yep
[21:05] <natefinch> perrito666: no sense having that kind of logic in more than one place
[21:06] <thumper> wallyworld_: dog got in a bit of a fight last night, off to the vet in just under an hour, she won't put weight on one of her legs :-(
[21:06] <wallyworld_> oh :-(
[21:06] <wallyworld_> hope she's ok
[21:06] <thumper> so do I
[21:06] <thumper> she isn't behaving normally
[21:07] <wallyworld_> :-(
[21:07] <thumper> was at the vet yesterday for ear infection
[21:07] <wallyworld_> $$$$$$
[21:07] <thumper> which may have made her a little short tempered
[21:07]  * thumper nods
[21:07] <wallyworld_> i'll ping you later after dinner here
[21:12] <wallyworld_> thumper: what do you mean by "name connection"?
[21:13] <thumper> wallyworld_: we are going to have 'juju connect' and use the name "connection" to refer to a particular thing
[21:13] <wallyworld_> thumper: this work will eventually kill the need for Environ to have to be able to provide mongo addresses
[21:13] <thumper> a connection is to an environment within a juju server as a user
[21:13] <thumper> wallyworld_: I'm happy that there is MongoInfo
[21:14] <thumper> I was just saying I didn't like axw's suggestion of calling it ConnectionInfo
[21:14] <wallyworld_> thumper: so Environ interface has StateInfo() returning a MongoInfo() and APIInfo()
[21:14] <wallyworld_> the MongoInfo return value will go away
[21:15] <thumper> because an Environ doesn't need it?
[21:15] <axw> thumper: yeah agreed, I mostly just didn't like the inconsistency
[21:15] <wallyworld_> Environ has no business knowing how the state persistence layer connects to mongo
[21:15] <thumper> axw: fair enough, consistency ftw
[21:15] <thumper> wallyworld_: agreed
[21:15] <wallyworld_> and i am about to propose a branch the means it doesn't have to
[21:16] <wallyworld_> thumper: you will be happy also with stuff that is being done to unpick State, will fill you in later
[21:16] <thumper> wallyworld_: ack
[21:16] <thumper> wallyworld_: next week is fine
[21:16] <wallyworld_> ok
[21:39] <dpb1> Hi all -- 1.20.1 + latest maas:  anyone seen this? http://paste.ubuntu.com/7777233/ (line 88)
[21:49] <thumper> dpb1: not seen it, but I don't test maas
[21:50]  * thumper off to the vet again
[21:58] <dpb1> thumper: OK... anyone else seen it? :)
[22:53] <waigani> thumper: https://github.com/juju/juju/pull/289