[01:45] <thumper> I'm finally happy with the tests around create environment now
[01:45] <thumper> on to manual testing
[01:47]  * thumper crosses fingers
[02:15] <mattyw> menn0, ping?
[02:23] <menn0> mattyw: pong
[02:48] <thumper> menn0: https://github.com/juju/juju/pull/1731
[02:48] <thumper> menn0: waiting for RB to pick it up
[02:49] <menn0> thumper: RB doesn't seem to want to
[02:50] <thumper> no...
[02:50] <menn0> thumper: shall I just review on GH
[02:50] <menn0> ?
[02:50] <thumper> sure
[03:15] <davecheney> mwhudson: the output from 7g -g is a total dogs breakfast
[03:16] <davecheney> it also appears this particular dog has barfed up the response, twice
[03:16] <davecheney> for good effect
[03:16] <mwhudson> is 6g -g any better?
[03:16] <davecheney> probaly not
[03:16] <davecheney> i've narrow the current crapping out
[03:16] <davecheney> to a nil check
[03:16] <davecheney> x := *y
[03:16] <davecheney> will generate a nil check
[03:16] <davecheney> and the encoding on that is screwed
[03:17] <mattyw> menn0, http://reviews.vapour.ws/r/1063/ when you have a moment
[03:18] <menn0> mattyw: looking
[03:19] <menn0> mattyw: ship it!
[03:20] <mattyw> menn0, thanks very much
[03:28] <axw> wallyworld: https://bugs.launchpad.net/juju-core/+bug/1420049 -- can you please see my latest comments on this
[03:28] <mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Fix Committed by dooferlad> <juju-core 1.22:In Progress by axwalk> <https://launchpad.net/bugs/1420049>
[03:29] <wallyworld> sure
[03:34] <wallyworld> axw: i think it might be reasonable to say that when deploying containers, we match the machine arch. even if they bootstrap with an env arch, and start a machine with a different explicitly set arch for that machine, it doesn't seem useful to go and use the env constraint when deploying a container without an arch when what we really want is just to match the host arch for lxc
[03:34] <wallyworld> deploying containers = lxc containers
[03:35] <axw> wallyworld: I suppose they only get into this scenario when using placement, so in that sense it's okay
[03:35] <wallyworld> yeah, i think so
[03:35] <axw> wallyworld: I'm worried about cornering ourselves though, where we might want to start adding containers to non-empty machines
[03:35] <axw> hmmm
[03:36] <axw> in that case it would be up to the placement code to match the constraint...
[03:36] <wallyworld> even in that case, add lxc container - arch should match host
[03:36] <axw> okay
[03:36] <wallyworld> if they explicitly speify an arch when deploying that is incompatible, then we error
[03:36] <wallyworld> but if we are just falling back to env arch, then we should "do the right thing"
[03:37] <wallyworld> eg, for kvm thy can specify different arch
[03:38] <beisner> o/  howdy
[03:38] <beisner> + addl response on bug 1420049
[03:38] <mup> Bug #1420049: ppc64el - jujud: Syntax error: word unexpected (expecting ")") <deploy> <openstack> <regression> <uosci> <juju-core:Triaged by axwalk> <juju-core 1.22:In Progress by axwalk> <https://launchpad.net/bugs/1420049>
[03:39] <axw> beisner: thanks. sorry, I glanced over the repro the first time (I can't easily repro since I don't have a multi-arch MAAS)
[03:39] <beisner> axw, np.  understandable.  the attached file count is growing on that bug ;-)
[03:43] <beisner> axw, feel free to ping me if we should try something different.  also, if/when you have a build to test, please point me at whatever ppa or CI/jenkins job has the debs?
[03:44] <axw> beisner: will do, thanks. the package building is a black box to me, but I'll keep an eye out for when they're available
[03:44] <beisner> axw, could also set up access for you, though that would take an RT -> vpn acl addition.   from there, we could coordinate access/creds.
[03:45] <beisner> axw, wallyworld & co., appreciate your work on this bug.
[03:45] <wallyworld> mainly axw :-)
[03:45] <axw> beisner: no worries, sorry it didn't get fixed the first time
[03:45] <wallyworld> it's been interesting because we don't normally deploy the same way
[03:46] <wallyworld> but it's a good use case to know about
[03:46] <beisner> axw - well actually it appears to really be 2 different bugs.  you got the 2-for-1 special.   i think one bug was fixed, revealing another.  but go is a blackbox to me.  ;-)
[03:47] <beisner> first issue being:   that funky syntax error
[03:47] <axw> I just shifted the bug :)
[03:47] <beisner> that was fixed
[03:48] <beisner> 2nd issue:  juju doesn't wanna use the same tools it just used to successfully deploy a unit onto the same dang box.  ;-)
[03:49] <beisner> wallyworld, yeah this is also an edge case for us.  normally everything is 1 arch.
[03:50] <wallyworld> for sure a customer will ht the issue too at some point
[03:50] <wallyworld> better we find it than them
[03:55] <beisner> yep indeed
[04:05] <wallyworld> axw: remind me, what's that lib for printing human readable volume sizes
[04:06] <axw> wallyworld: github.com/dustin/go-humanize
[04:07] <wallyworld> axw: ta, doesn't look like we use that in master?
[04:07] <axw> wallyworld: nope, I added it in the feature branch
[04:07] <wallyworld> ok, i'll look to add it
[04:30] <mattyw> menn0, still around?
[04:31] <menn0> mattyw: yep
[04:53] <axw> wallyworld: how would we surface an error like that? in the provisioner, we don't know the origin of the constraints
[04:54] <wallyworld> axw: at add-machine or deploy time we have the info
[04:54] <axw> wallyworld: placement explicitly overrides constraints though, so I don't think it makes sense?
[04:54] <wallyworld> so we can return the error from apiserver layer
[04:55] <wallyworld> ah
[04:55] <wallyworld> yes, i forgot that
[04:56] <wallyworld> what abut add machine
[04:56] <wallyworld> will placement override constraints there too
[04:57] <axw> wallyworld: I'm under the impression that placement always overrides constraints
[04:57] <wallyworld> so juju add-machine --constraints mem=2G lxc
[04:58] <wallyworld> will ignore the constraints?
[04:58] <wallyworld> i guess there it doesn't matter
[04:58] <wallyworld> as a new machine will be created
[04:58] <wallyworld> so arch will not skew
[04:59] <wallyworld> i'll revert my comment
[05:00] <axw> wallyworld: ignore is too strong a word I guess. it may override aspects of them, or all of them
[05:01] <axw> wallyworld: e.g. add-machine ssh:... will ignore the env constraints (or should)
[05:02] <wallyworld> ok, i was just concerned about surprising behaviour
[05:02] <thumper> axw: thanks for fixing the lxc tools selection
[05:02] <wallyworld> ie if the user specifies an arch constraint of one thing and the lxc container comes up on another arch
[05:02] <axw> thumper: no worries
[05:03] <axw> wallyworld: that was my complaint before. I'm not sure how to resolve it
[05:03] <wallyworld> yeah
[05:03] <axw> you could prevent "deploy --constraints=<incompatible> --to lxc:N"
[05:04] <axw> doesn't seem worthwhile though
[05:07] <wallyworld> maybe something to fix to improve UI, but not for now
[05:08] <wallyworld> axw: at first read the TestLxcContainerUsesConstraintsArch() seems wrong? host arch set to ppc64, expect arch amd64?
[05:09] <axw> wallyworld: I just named the tests back-to-front
[05:09] <axw> will fix
[05:09] <wallyworld> ta, i thought i was going mad
[05:09] <wallyworld> i misse dthe mrthod param
[05:15] <wallyworld> thumper: cmd/juju/environment/create.go:128: no formatting directive in Errorf call
[05:29] <axw> wallyworld: have you pulled master today? are the tests in environs/manual failing for you?
[05:29] <axw> looks upstart/systemd-related
[05:30] <wallyworld> axw: i'll check
[05:31] <wallyworld> axw: this? FAIL: provisioner_test.go:47: provisionerSuite.TestProvisionMachine
[05:31] <axw> wallyworld: yes
[05:31] <axw> le sigh
[05:31] <axw> thanks
[05:31] <wallyworld> how the fark did that get past the bot
[05:34] <jw4> wallyworld: do you know why the build didn't fail when the verify.bash script got the "no formatting directive in Errorf call" ?
[05:34] <jw4> wallyworld: I'm nervous it was due to my IGNORE_VET_WARNINGS change from a couple weeks ago
[05:34] <wallyworld> jw4: i don't think we run vet on the bot
[05:34] <wallyworld> or i seem to recall we used not to
[05:35] <jw4> wallyworld: hmm - I see the warning in the last build output
[05:35] <jw4> http://juju-ci.vapour.ws:8080/job/github-merge-juju/2372/console
[05:35] <jw4> maybe we just don't fail if it exits non-zero
[05:35] <wallyworld> yes, i think that may be what we do :-(
[05:36] <jw4> wallyworld: well I feel better if I didn't break it :)
[05:36] <wallyworld> i don't think you did
[05:36] <jw4> FWIW, I've been getting a lot of provisioner test failures too
[05:36] <wallyworld> which package?
[05:36] <wallyworld> manual?
[05:36] <jw4> yeah
[05:36] <wallyworld> seems they started today
[05:36] <jw4> for me it seems to be related to OpenSSH and ubuntu@lxc
[05:37] <jw4> I've been getting it for at least a week
[05:37] <wallyworld> NFI how the bot let any breakage through
[05:37] <wallyworld> oh i see
[05:37] <axw> wallyworld: there's a map
[05:37] <axw> linuxExecutables in service/service.go
[05:37] <wallyworld> well that would explain it
[05:38] <wallyworld> i'm on go 1.3
[05:38] <wallyworld> the bot runs 1.2
[05:38] <wallyworld> le sigh indeed
[05:38] <axw> I'm on 1.4 :)
[05:38] <axw> I'll fix
[05:38] <jw4> yeah, I'm on 1.4 too
[05:38] <jw4> my first recorded error there was on 2/28 fwiw
[05:50] <axw> wallyworld: small one please: https://github.com/juju/juju/pull/1738
[05:50] <wallyworld> sure
[05:52] <wallyworld> axw: LGTM. i have to go get kid, could you please send email to juju-dev highlighting what happened and cc curtis and wes. We need to change how we land to stop this happening again
[05:52] <wallyworld> we will likely gate landings on gccgo tests passing
[05:53] <wallyworld> this will add another reason for doing that
[05:53] <axw> wallyworld: ok
[05:53] <wallyworld> tyvm
[06:09] <axw> jw4: what was the problem that let to IGNORE_VET_WARNINGS again?
[06:10] <jw4> axw: I've brought up go vet warnings from newer versions of go several times
[06:10] <jw4> axw: most times the answer is... go 1.2.1 is the official version
[06:10] <jw4> axw: to make it easy for folks to use newer versions of go and still have the pre-push hook
[06:10] <jw4> axw: I added that envar so that at least bypassing it is explicit rather than implicit
[06:10] <axw> jw4: I see. and we can't modify the rules to work with both 1.2 and 1.4?
[06:11] <jw4> axw: I'm not sure I understand - as I understand it the vet rules are largely determined by the version of go you're using
[06:12] <jw4> axw: we have flags we pass in but those don't seem to be useful for this sort of thing
[06:12] <axw> jw4: you can customise the functions that are considered printf-style, as in scripts/verify.bash
[06:12] <axw> ok
[06:12] <jw4> axw: yeah - tweaking those hasn't addressed the issue in the past
[06:13] <axw> jw4: I don't see any vet warnings/errors, I'm on 1.4. do you still need to do this at the moment?
[06:13] <axw> or was the source changed?
[06:13] <jw4> axw: the source was changed
[06:13] <jw4> axw: I think it makes sense to have that guard in there anyway
[06:14] <axw> jw4: yep, it's fine since it's explicit - just wanted to understand
[06:14] <axw> thanks
[06:14] <jw4> yw, thank you
[06:26] <mattyw> menn0, are you done for the day?
[06:56] <wallyworld> axw: thanks for email, was well written
[07:09] <axw> wallyworld: cool, nps
[08:35] <jam> fwereade: when you're around say hi
[09:00] <tasdomas> dimitern, ping?
[09:00] <dimitern> tasdomas, hey
[09:01] <tasdomas> dimitern, mattyw is afk at the moment, but he asked me to ask you to take a look at http://reviews.vapour.ws/r/994/
[09:01] <dimitern> tasdomas, yes, I know - will get to it at some point
[09:01] <tasdomas> dimitern, ok - no problem
[09:01] <dimitern> tasdomas, cheers
[09:02] <tasdomas> dimitern, another question - with the laster master of juju, I'm getting test failures in api/networker and apiserver/networker
[09:03] <tasdomas> is this a known issue?
[09:03] <dimitern> tasdomas, oh - can you paste them?
[09:03] <tasdomas> dimitern, sure, one sec
[09:03] <dooferlad> Morning! o/
[09:04] <dimitern> dooferlad, morning!
[09:04] <dimitern> dooferlad, did you know that it's valid in go to do: x, y = y,x ?
[09:04] <dooferlad> dimitern: I had forgotten. Not a language feature I am used to.
[09:05] <tasdomas> by the way, is there a recommendation as to which version of go should be used for juju development ?
[09:05] <dimitern> tasdomas, 1.2.1 - the version in precise and trusty
[09:06] <dimitern> tasdomas, we need to make sure it works on 1.2.1 that is, it's fine if you use a more recent version otherwise
[09:07] <dimitern> dooferlad, yeah, I was looking at that PR of yours and noticed a place where you swap two volume items in a deeply nested set of slices
[09:08] <dooferlad> dimitern: I think other than rebasing it to the head of trunk the code is OK now. Just need to get code.google.com/p/gcfg ok as a dependency.
[09:09] <dimitern> jam, I know we discussed a policy about having 2 team leads at least approve adding a new external dependency, but how about if it's only used for tests?
[09:10] <TheMue> morning o/
[09:11] <TheMue> dimitern: thanks for retry my merge. just wanted to do it and wondered where it is. :D
[09:11] <dimitern> TheMue, morning, np :)
[09:11] <jam> dimitern: probably the biggest thing for me is that if it is just for testing, then it can't be a strong enough dependency that we should actually need it
[09:12] <jam> dimitern: in this case, we have a pretty strong preference for YAML in our codebase (or possibly JSON)
[09:12] <dimitern> jam, it's just for testing
[09:12] <dimitern> jam, and it's a about parsing INI-style files (like systemd uses)
[09:13] <dimitern> jam, the alternative is to implement an INI parser ourselves
[09:13] <jam> dimitern: that's definitely something I see creeping past "just testing" very quickly
[09:13] <jam> I'm not saying we don't want it, just that it should follow the normal review for dependencies
[09:14] <dimitern> jam, this is the dependency in question - code.google.com/p/gcfg and the PR that uses it is this https://github.com/juju/juju/pull/1718
[09:20] <jam> dimitern: "some tests don't generate valid ini files" doesn't sound like a good mix with nondeterministic ordering
[09:21] <jam> at best it feels like the test is "more likely to pass" but it doesn't actually get us to determinism
[09:21] <dooferlad> jam: it isn't about generating the files, it is parsing them. The order of items in those files isn't deterministic.
[09:22] <jam> dooferlad: I fully understand that part.
[09:22] <jam> but your fix is that "sometimes we'll parse them because sometimes the data can't be parsed"
[09:22] <jam> and what happens when the "data that can't be parsed" ends up the one that is non-deterministic order
[09:22] <dimitern> dooferlad, yeah, that statement is a bit worrying
[09:23] <jam> dooferlad: offhand I'd rather we just made the way config files are *written* deterministic
[09:23] <jam> even if it means sorting the map keys before iterating them
[09:23] <dooferlad> jam: it compares the strings because sometimes we don't output an ini file during the test. Sometimes we have "a\nb\nc" for example.
[09:23] <jam> dooferlad: put another way. It sounds like a problem if our config writer is iterating over maps as much as it is a problem if our tests do
[09:23] <tasdomas> dimitern, http://paste.ubuntu.com/10524916/ and http://paste.ubuntu.com/10524897/
[09:25] <dimitern> tasdomas, this looks like a map ordering issue - which version of go are you using?
[09:25] <tasdomas> dimitern, 1.4
[09:25] <tasdomas> dimitern, I can try switching to 1.2
[09:26] <dimitern> tasdomas, yeah, it will pass with 1.2, but the test needs to be fixed nevertheless
[09:26] <dooferlad> jam: agreed. I would rather that the configs were outputted with sorted keys just from a user POV - I would rather we could diff our ini files to see what changed.
[09:26] <dimitern> tasdomas, would you do me a favor and file a bug for it if it doesn't exist yet?
[09:28] <TheMue> dimitern: where to investigate next regarding networking?
[09:29] <tasdomas> dimitern, sure
[09:29] <dimitern> TheMue, I'll have a review for you shortly
[09:29] <dimitern> tasdomas, thanks!
[09:29] <TheMue> dimitern: great, pressing refresh in dashboard every second now *lol*
[09:30] <jam> dimitern: dooferlad: so aside from the specifics of these tests, being able to easily parse the files we're writing sounds useful, and reasonable to have as a dependency so we don't have to reimplement it ourselves
[09:30] <jam> one small concern
[09:30] <jam> is that gcfg doesn't have any sort of guarantee that it parses the way systemd does. does it?
[09:31] <dooferlad> jam: No, ini files are not standardised.
[09:32] <dimitern> TheMue, :) it's a long one let me warn you, but it does 99% of what's left around container addressability
[09:33] <TheMue> dimitern: it's ok, can imagine what to expect
[09:33] <dimitern> TheMue, I was live testing it (and fixing some places as a result) on both EC2 and MAAS for the past 2 days
[09:34]  * dimitern well now! isn't this just beautiful: http://paste.ubuntu.com/10525017/
[09:35] <dooferlad> dimitern: :-D
[09:35] <TheMue> dimitern: ouch, neat, that looks cool
[09:42] <dimitern> TheMue, dooferlad, there it is http://reviews.vapour.ws/r/1072/
[09:43] <TheMue> *click*
[09:43]  * dimitern looks at the diff, which is slightly shy of 1000 lines 
[09:45] <dooferlad> jam, dimitern: Oops. We already have go-systemd, which has a unit Deserialise function. Will switch to that. I will still need to work around unparsable strings, but it won't add a dependency.
[09:45] <dimitern> dooferlad, oh, that sgtm then
[09:46] <dooferlad> dimitern: you are the reason why http://www.internetslang.com/ exists :-)
[09:47] <dimitern> dooferlad, I knew it :)
[09:50] <axw> dimitern: FYI there were some changes to worker/provisioner for LXC today, may need a minor merge if you haven't already done so
[09:50] <axw> the pastebin looks nice :)
[09:50] <dimitern> axw, I did - fortunately small conflict
[09:51] <dimitern> axw, it does, doesn't it? :) and here's the one for maas: http://paste.ubuntu.com/10525174/
[09:52] <dimitern> (some stuff needs ironing out it seems)
[09:54] <axw> very cool, glad to see it come to fruition
[09:57] <dimitern> :) thanks axw
[10:00] <dimitern> dooferlad, TheMue, I'm omw in ~2m
[10:00] <TheMue> kk
[10:05] <gnuoy> Hi, I'd like to start prodding at the leadership election function. I had thought it was in 1.23-alpha1.1 but it seems not. Is there anywhere I can grab an alpha version of juju that has it in ? Failing that is there a bug I can track?
[10:33] <wallyworld> natefinch: is there anyone on your team who knows about mongo replica sets who can look at bug 1346597? the relevant error seems to be "not authorized for query on local.system.replset"
[10:33] <mup> Bug #1346597: cannot get replset config: not authorized for query on local.system.replset <cloud-installer> <landscape> <oil> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1346597>
[10:33] <wallyworld> this is currently blocking 1.22 and 1.23
[10:41] <natefinch> wallyworld: sure
[10:41] <wallyworld> tyvm
[10:41] <natefinch> wallyworld: usually it's just that we'
[10:41] <natefinch> we're not running as admin somehow
[10:41] <wallyworld> we've fixed or are fixing the other 2 so are close to being able to release 1.22
[10:42] <wallyworld> natefinch: it's on oil so maybe a deployment or setup issue?
[10:45] <perrito666> hey, there is not much worth of me as I am about to go back to bed and feel bad, but https://bugs.launchpad.net/juju-core/+bug/1346597 after comment 4 looks all kinds of invalid to me
[10:45] <mup> Bug #1346597: cannot get replset config: not authorized for query on local.system.replset <cloud-installer> <landscape> <oil> <juju-core:Triaged> <juju-core 1.22:Triaged> <https://launchpad.net/bugs/1346597>
[10:46] <natefinch> wallyworld: it could be a bug... looking at the logs now
[10:46] <wallyworld> ok
[10:46] <natefinch> 862473
[10:46] <wallyworld> perrito666: get well soon :-)
[10:47] <perrito666> wallyworld: tx, I think soup and wather should get me on my feet soon and in the mean time getting some more sleep could help
[10:47] <wallyworld> indeed.
[10:47] <perrito666> anyway, comment 4 on taht bug says that the mongo was a leftover from a dirty machine
[10:47] <wallyworld> perrito666: i could run your status-get hook tool to poll your health :-)
[10:48]  * perrito666 imagines getting paper notes with rpc calls every couple of seconds
[10:49] <wallyworld> perrito666: i *think* they said the latest occurrence was on a fresh instance, but am not sure
[10:49] <perrito666> wallyworld: that bug means you are neither admin nor the machine-0 tag user (which is odd)
[10:50] <wallyworld> perrito666: yeah, it may pay to ping jason on irc to ask some questions about their set up
[10:51] <natefinch> I'm assuming any comments on that bug from earlier than this month are unrelated
[10:57] <perrito666> you might notice in the logs that all credentials are empty in the dial info
[10:58] <perrito666> anyway, I would ask for the agent.conf as it might shed some light, ill go to sleep before I die on my laptop bbl
[11:05] <mup> Bug #1428074 was filed: api/networker and apiserver/networker tests fail <juju-core:New> <https://launchpad.net/bugs/1428074>
[11:06] <mup> Bug #1428074 changed: api/networker and apiserver/networker tests fail <juju-core:New> <https://launchpad.net/bugs/1428074>
[11:16] <mup> Bug #1428074 was filed: api/networker and apiserver/networker tests fail <juju-core:New> <https://launchpad.net/bugs/1428074>
[11:17] <dimitern> dooferlad, btw I've discovered that (for maas at least) in addition to enabling ip forwarding we need to enable proxy_arp as well, otherwise containers on another host cannot resolve the state server's ip
[11:24] <TheMue> dimitern: you've got a review
[11:24] <dimitern> TheMue, thanks!
[11:24] <TheMue> dimitern: yw
[11:28] <TheMue> aaargh, once again a map ordering issue
[11:36] <tasdomas> dimitern, re the bug I filed - I can still reproduce it using go 1.2.1 (built from source)
[11:37] <dimitern> tasdomas, oh really? that's worse than I though then
[11:38] <tasdomas> dimitern, the fact that nobody else has reproduced this makes me think that I'm doing something wrong
[11:38] <dimitern> tasdomas, let me try
[11:39] <wallyworld> dimitern: bug 1428074 - IMHO any test failure related to map ordering should be no lower than high, even critical
[11:39] <mup> Bug #1428074: api/networker and apiserver/networker tests fail <juju-core:Triaged> <https://launchpad.net/bugs/1428074>
[11:39] <dimitern> tasdomas, why don't you try using golang-go package from the trusty main archive?
[11:40] <tasdomas> dimitern, that's what Im about to do
[11:40] <wallyworld> they will fail on gccgo and for those of us running go > 1.2 (there are many)
[11:40] <wallyworld> and they are easy to fix
[11:40] <dimitern> wallyworld, I'm investigating
[11:40] <wallyworld> ok
[11:40] <wallyworld> ty
[11:40] <dimitern> wallyworld, will change as needed
[11:40] <wallyworld> i just saw the triage to medium :-)
[11:41] <dimitern> wallyworld, I was not aware of that decision (about map ordering issues needing to be no less than high)
[11:42] <dimitern> tasdomas, I can't reproduce it with 1.2.1 gccgo, which means it's not a map ordering issue then
[11:43] <tasdomas> dimitern, it is or it isn't ?
[11:43] <wallyworld> dimitern: it's my opinion - i think it's a fundamental code flaw that shold be fixed as it is almost guaranteed to fail unit tests
[11:43] <dimitern> tasdomas, :) sorry - it is not
[11:43] <dooferlad> dimitern: I have a fix without a new library. It does involve a change to juju/testing/checkers/checker.go though.
[11:43] <dimitern> dooferlad, I'll have a look shortly
[11:43] <wallyworld> deterministically failing tests are critical, especially those we can fix
[11:43] <dimitern> dooferlad, why the change to checkers?
[11:44] <dimitern> wallyworld, fair enough
[11:44] <dooferlad> dimitern: so I can optionally dereference pointers in checkSameContents
[11:44] <wallyworld> dimitern: ty. it means that gccgo and those of us running > 1.2 can get clean test runs
[11:44] <dooferlad> dimitern: created a new check: SameContentsDeref
[11:44] <wallyworld> and avoid nasty tech debt for later
[11:45] <wallyworld> when we upgrade go toolchain
[11:45] <dimitern> wallyworld, +1 that sgtm
[11:46] <dimitern> tasdomas, bad news - I can't reproduce it with 1.4.2 either
[11:46] <tasdomas> dimitern, great, thanks
[11:46] <dimitern> tasdomas, I'll comment on the bug
[11:47] <tasdomas> dimitern, ack
[11:52] <dimitern> dooferlad, have you pushed the changes?
[11:52] <dooferlad> dimitern: just doing so now
[11:52] <dimitern> ok
[11:53] <dooferlad> dimitern: pushed
[11:53] <dooferlad> dimitern: https://github.com/juju/testing/compare/master...dooferlad:master-deref is the testing branch change
[11:54] <dooferlad> dimitern: Oh, and I need to remove the change to dependencies.tsv. That will arrive shortly.
[11:55] <dimitern> dooferlad, can you expand a bit why the Indirect was needed?
[11:57] <dooferlad> dimitern: because comparing pointers wasn't useful :-) Basically, we were comparing two lists of pointers and reflect.DeepEqual wasn't following them, only examining their value.
[11:57] <dooferlad> dimitern: or at least that seemed to be the case.
[11:57] <dooferlad> dimitern: without the change, the test failed. With the change it passed 100 times in a row.
[11:57] <mup> Bug #1428074 changed: api/networker and apiserver/networker tests fail <juju-core:Triaged> <https://launchpad.net/bugs/1428074>
[11:58] <dimitern> dooferlad, ok, great
[11:59] <dimitern> dooferlad, this change seems useful enough to be unconditionally applied to SameContents checker I think
[11:59] <dooferlad> dimitern: do I propose the juju/testing branch in the same way as juju/juju?
[11:59] <dimitern> dooferlad, but it needs more tests as well in juju/testing
[12:00] <dooferlad> dimitern: seems reasonable
[12:00] <dimitern> dooferlad, however, I'd like you to scan our juju/* repos for places SameContents is used and see if making the change will break anything
[12:00] <dimitern> dooferlad, there should be a very few places indeed
[12:02] <dimitern> dooferlad, as for how to propose it - the usual way - fork juju/testing to your account, wipe out your $GOPATH/src/github.com/juju/testing/ repo, clone your fork in the same place, add upstream remote to the master repo, etc.
[12:09] <anastasiamac> dimitern: goamz v3 regions is missing 2 that i can see... is it possible or m i looking in the wrong place?
[12:09] <dimitern> anastasiamac, which ones?
[12:09] <anastasiamac> dimitern: EU (Frankfurt)	eu-central-1
[12:10] <dimitern> anastasiamac, that one was never added
[12:10] <dimitern> IIRC
[12:10] <anastasiamac> dimitern: i was looking at prices and there is a price for it...
[12:10] <anastasiamac> dimitern: another one that comes up is AWS GovCloud in US
[12:10] <anastasiamac> dimitern: shall i just ignore these 2 then?...
[12:11] <dimitern> anastasiamac, prices?
[12:11] <dimitern> anastasiamac, you mean in juju source?
[12:11] <anastasiamac> dimitern: http://aws.amazon.com/ec2/pricing/
[12:11] <anastasiamac> dimitern: and putting updating them in juju for bug 1427840
[12:11] <mup> Bug #1427840: ec2 provider unaware of c3 types in sa-east-1 <juju-core:In Progress by anastasia-macmood> <https://launchpad.net/bugs/1427840>
[12:12] <dimitern> anastasiamac, oh, of course - they are indeed available and used (not sure about the gov one - you should be working for the us gov perhaps)
[12:12] <dimitern> anastasiamac, but since both are fairly new goamz doesn't yet have them
[12:13] <dimitern> anastasiamac, there was even a bug  filed somewhere that eu-central-1 is missing
[12:13] <anastasiamac> dimitern: k, so m put n them in on our side intoec2/instancetype
[12:13] <dimitern> anastasiamac, yes, unless you need them I think you can safely ignore them :)
[12:14] <dimitern> anastasiamac, that was too concise for me to understand, sorry :)
[12:14] <anastasiamac> dimitern: i think that i could get away with putting them into struct as string... and then goamz will need to be updated...
[12:15] <anastasiamac> dimitern: m adding the prices for these 2 regions into ec2/instancetype as they are specified by string :D
[12:15] <anastasiamac> dimitern: but on goamz side they r still missing as regions :D
[12:15] <dimitern> anastasiamac, ah, so you do need them?
[12:16] <anastasiamac> dimitern: if the pricing is on aws website, do i need to have it in juju?... I would have thought that the answer is "yes"
[12:16] <anastasiamac> dimitern: unless our point of truth is goamz and not aws source...
[12:16] <anastasiamac> dimitern: no?
[12:17] <dimitern> anastasiamac, well, think about it this way: we only support what we have tested, so unless you need to test stuff on those regions and need the pricing for them
[12:18] <dimitern> anastasiamac, then yes, add them but also update goamz and test it works on the new regions
[12:18] <anastasiamac> dimitern: k. considering that we are close to 1.23, I'd rather file a bug and deal with these 2 rgions once we branch :D
[12:18] <dimitern> anastasiamac, in any case I'd suggest posting a message to juju-dev first
[12:18] <dimitern> anastasiamac, sgtm
[12:19] <anastasiamac> dimitern: tyvm :D
[12:25] <dimitern> TheMue, btw here's the PR with megawatcher tests I was talking about - https://github.com/juju/juju/pull/1588/files
[12:26] <TheMue> dimitern: ah, great, just creating a card for it
[12:26] <dimitern> TheMue, cheers!
[13:00] <mup> Bug #1428117 was filed: EC2 eu-central-1 region not in provider <juju-core:New> <https://launchpad.net/bugs/1428117>
[13:00] <mup> Bug #1428119 was filed: EC2 provider does not include C4 instance family <juju-core:New> <https://launchpad.net/bugs/1428119>
[13:45] <wallyworld> natefinch: forgot to ask, you still working on bug 1415671 as it is assigned to 1.23 beta1?
[13:45] <mup> Bug #1415671: Joyent provider uploads user's private ssh key by default <joyent-provider> <juju-core:Triaged by natefinch> <https://launchpad.net/bugs/1415671>
[14:39] <natefinch> wallyworld: oh, sorry, I dropped the ball on that one.  I'll send an email to the list and maybe we can discuss at the team lead meeting if there's no resolution on it - it's kind of tricky.
[14:39] <wallyworld> sure, ok
[14:40] <natefinch> wallyworld: basically... the thought had been to generate an SSH key, but we can't just upload a new key for someone to their joyent account
[14:40] <wallyworld> may need to do something that's less automatic but secure
[14:40] <wallyworld> document the process
[14:41] <natefinch> yep
[14:41] <natefinch> I think the right answer might just be "you have to specify the SSH key in the config, and if you don't, we'll complain about it"
[14:42] <natefinch> That's basically the way the rest of the providers work - you have to provide the auth, we don't make it for you
[14:48]  * dimitern steps out for ~30m
[15:05] <ericsnow> natefinch, wwitzel3: standup?
[15:32] <ericsnow> dooferlad: I've followed up on your review request
[15:32] <ericsnow> dooferlad: thanks for tackling that
[15:33] <ericsnow> dooferlad: what can I do to help get that landed today?
[15:34] <dooferlad> ericsnow: I just landed a change to juju/testing, which should be all I need now.
[15:35] <dooferlad> ericsnow: just updating dependencies.tsv and re-testing
[15:35] <ericsnow> dooferlad: you've already rebased/merged against master?
[15:36] <dooferlad> ericsnow: yes, it is now ready to land once I have confirmed my change to juju/testing is being picked up correctly.
[15:36] <ericsnow> dooferlad: sweet!
[15:50] <katco> 0/?pli=1#inbox/who
[15:50] <katco> lol oops
[15:52] <mgz> #blameemacs
[15:53] <katco> lol
[15:53] <dimitern> mgz, hey there
[15:54] <mgz> dimitern: I will have good news for you shortly
[15:54] <dimitern> mgz, :) awesome
[15:54] <mgz> dimitern: we may was to add a dependecy.tsv to goose at some point though, atm I've passing through at the merge level which is annoying if deps change
[15:55] <dimitern> mgz,
[15:55] <dimitern> mgz, sorry, could you rephrase that a bit? :)
[15:57] <mgz> dimitern: we don't manage dependencies of goose currently (it only has a few) - if we get to adding more we may want something explicit like a dependencies.tsv otherwise a dep change means a jenkins job change
[15:57] <mgz> any clearer?
[15:57] <dimitern> mgz, yes, thanks
[15:57] <dimitern> mgz, that sounds good to me - we'll add dependencies.tsv then
[15:58] <mgz> don't need it quite yet, but worth it later I think
[15:58] <dimitern> mgz, is that also the main obstacle to adding other sub-repos under the merge bot?
[15:59] <mgz> nah, there are a few minor differences that mean it's some extra each time but it gets easier to add new jobs every time
[15:59] <mgz> like, some of them down't pass their own test suites currently
[15:59] <dimitern> ok, great
[16:00] <mgz> so, it's just stuff to get fixed
[16:00] <dimitern> really? that's pretty bad
[16:00] <dimitern> mgz, I'd really appreciate if you can send me a list of these failures, if you have it
[16:01] <ericsnow> fwereade: you free to meet?
[16:24] <alexisb> dimitern, ping
[16:24] <dimitern> alexisb, pong
[16:24] <alexisb> hey there
[16:24] <dimitern> hey, what's up?
[16:25] <alexisb> for that mailing list thread "unit-get and ipv6 addresses"
[16:25] <alexisb> we should have jake open a bug
[16:25] <dimitern> yes, i've looked at it briefly, but still couldn't find a reason why it's happening
[16:26] <dimitern> I'll respond and ask for a bug report
[16:27] <alexisb> thanks
[16:28] <dimitern> np
[16:40] <dimitern> tasdomas, 994 is reviewed
[16:41] <dimitern> alexisb, replied
[16:42] <alexisb> dimitern, saw it and thank you
[17:28] <ericsnow> dooferlad: thanks for landing that!
[17:29] <dooferlad> ericsnow: no worries!
[20:47] <tasdomas> dimitern, thanks
[21:11]  * thumper sadface
[21:11] <thumper> / The config generate here will be store in a config file and in the state DB.
[21:11] <thumper> does not make grammatical sense
[21:11] <thumper> it is like someone doesn't like 'd's
[21:12] <perrito666> thumper: that is almost not politically correct
[21:13] <natefinch> not everyone speaks english as a first language... I tend to give people a pass if they make minor grammatical errors (I do correct them, but don't make a big deal of it)
[21:16] <natefinch> people that write unit tests which start web servers should be flogged
[21:17] <perrito666> natefinch: not everyone speaks unit tests as a first testing choice... :p
[21:17] <natefinch> :p
[21:17] <thumper> lol
[21:19] <natefinch> http: panic serving 127.0.0.1:52936: runtime error: slice bounds out of range
[21:19]  * perrito666 had to google flogged, in Argentina is an anglicism meaning "added an entry in his/hers foto log"
[21:19]  * thumper frowns
[21:19] <thumper> I'm sure this code exists elsewhere
[21:19]  * thumper hunts
[21:19] <natefinch> joyent tests evidently run not one but two http servers
[21:21] <perrito666> adding fields to status is a royal pain in the rear
[21:41] <ericsnow> menn0: FYI, I addressed your comments in and added tests to http://reviews.vapour.ws/r/1059/
[21:43] <menn0> ericsnow: looking
[21:54] <mwhudson> thumper: i bet you know this, is there a way when using flag.FlagStr to tell the difference between the arg being passed with the default value and the arg not being passed?
[21:55] <mwhudson> flag.StringVar rather
[21:55] <menn0> ericsnow: ship it with tiny fixes
[21:55] <ericsnow> menn0: cool, thanks
[22:06] <mup> Bug #1428345 was filed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
[22:06] <mup> Bug #1428345 changed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
[22:07] <mup> Bug #1428345 was filed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
[22:07] <mup> Bug #1428345 changed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
[22:07] <mup> Bug #1428345 was filed: unit-get private-address returns ipv6 address <juju-core:New> <https://launchpad.net/bugs/1428345>
[22:13] <perrito666> here I was trying to fix my 4 broken tests... now I have 15 ... how did that happened
[22:14] <cherylj> mwhudson: I'm curious why you ask?  I think you could not set a default value (use ""), and then in the Init set that value if it's not specified
[22:15] <mwhudson> cherylj: wanted to have a flag use a computed default value, but have -r "" be different
[22:15] <mwhudson> it's probably a bad idea :)
[22:15] <mwhudson> (it's also for something that's only going to be invoked by the go tool in practice so something more explicit can be done instead)
[22:16] <cherylj> mwhudson:  ah, I was just curious.  I've been digging through the gnuflag docs to determine if there's a way to say you can only specify a flag once.
[22:23] <thumper> anyone up for a quick review? http://reviews.vapour.ws/r/1076/diff/#
[22:25] <ericsnow> thumper: I'll look
[22:25] <thumper> ericsnow: cheers
[22:25] <ericsnow> thumper: was it very hard adding that to GCE?
[22:25] <thumper> nope
[22:25] <ericsnow> thumper: oh good
[22:25] <thumper> just moved functions around
[22:55] <ericsnow> thumper: I've posted a review (just 1 issue to resolve)