thumper | I'm finally happy with the tests around create environment now | 01:45 |
---|---|---|
thumper | on to manual testing | 01:45 |
* thumper crosses fingers | 01:47 | |
mattyw | menn0, ping? | 02:15 |
menn0 | mattyw: pong | 02:23 |
thumper | menn0: https://github.com/juju/juju/pull/1731 | 02:48 |
thumper | menn0: waiting for RB to pick it up | 02:48 |
menn0 | thumper: RB doesn't seem to want to | 02:49 |
thumper | no... | 02:50 |
menn0 | thumper: shall I just review on GH | 02:50 |
menn0 | ? | 02:50 |
thumper | sure | 02:50 |
davecheney | mwhudson: the output from 7g -g is a total dogs breakfast | 03:15 |
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:16 |
mattyw | menn0, http://reviews.vapour.ws/r/1063/ when you have a moment | 03:17 |
menn0 | mattyw: looking | 03:18 |
menn0 | mattyw: ship it! | 03:19 |
mattyw | menn0, thanks very much | 03:20 |
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:28 |
wallyworld | sure | 03:29 |
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:34 |
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:35 |
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:36 |
wallyworld | eg, for kvm thy can specify different arch | 03:37 |
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:38 |
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:39 |
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:43 |
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:44 |
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:45 |
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:46 |
beisner | first issue being: that funky syntax error | 03:47 |
axw | I just shifted the bug :) | 03:47 |
beisner | that was fixed | 03:47 |
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:48 |
beisner | wallyworld, yeah this is also an edge case for us. normally everything is 1 arch. | 03:49 |
wallyworld | for sure a customer will ht the issue too at some point | 03:50 |
wallyworld | better we find it than them | 03:50 |
beisner | yep indeed | 03:55 |
wallyworld | axw: remind me, what's that lib for printing human readable volume sizes | 04:05 |
axw | wallyworld: github.com/dustin/go-humanize | 04:06 |
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:07 |
mattyw | menn0, still around? | 04:30 |
menn0 | mattyw: yep | 04:31 |
axw | wallyworld: how would we surface an error like that? in the provisioner, we don't know the origin of the constraints | 04:53 |
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:54 |
wallyworld | ah | 04:55 |
wallyworld | yes, i forgot that | 04:55 |
wallyworld | what abut add machine | 04:56 |
wallyworld | will placement override constraints there too | 04:56 |
axw | wallyworld: I'm under the impression that placement always overrides constraints | 04:57 |
wallyworld | so juju add-machine --constraints mem=2G lxc | 04:57 |
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:58 |
wallyworld | i'll revert my comment | 04:59 |
axw | wallyworld: ignore is too strong a word I guess. it may override aspects of them, or all of them | 05:00 |
axw | wallyworld: e.g. add-machine ssh:... will ignore the env constraints (or should) | 05:01 |
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:02 |
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:03 |
axw | doesn't seem worthwhile though | 05:04 |
wallyworld | maybe something to fix to improve UI, but not for now | 05:07 |
wallyworld | axw: at first read the TestLxcContainerUsesConstraintsArch() seems wrong? host arch set to ppc64, expect arch amd64? | 05:08 |
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:09 |
wallyworld | thumper: cmd/juju/environment/create.go:128: no formatting directive in Errorf call | 05:15 |
axw | wallyworld: have you pulled master today? are the tests in environs/manual failing for you? | 05:29 |
axw | looks upstart/systemd-related | 05:29 |
wallyworld | axw: i'll check | 05:30 |
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:31 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
axw | wallyworld: small one please: https://github.com/juju/juju/pull/1738 | 05:50 |
wallyworld | sure | 05:50 |
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:52 |
wallyworld | this will add another reason for doing that | 05:53 |
axw | wallyworld: ok | 05:53 |
wallyworld | tyvm | 05:53 |
axw | jw4: what was the problem that let to IGNORE_VET_WARNINGS again? | 06:09 |
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:10 |
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:11 |
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:12 |
=== Murali_ is now known as Murali | ||
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:13 |
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:14 |
mattyw | menn0, are you done for the day? | 06:26 |
wallyworld | axw: thanks for email, was well written | 06:56 |
axw | wallyworld: cool, nps | 07:09 |
jam | fwereade: when you're around say hi | 08:35 |
tasdomas | dimitern, ping? | 09:00 |
dimitern | tasdomas, hey | 09:00 |
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:01 |
tasdomas | dimitern, another question - with the laster master of juju, I'm getting test failures in api/networker and apiserver/networker | 09:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:07 |
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:08 |
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:09 |
TheMue | morning o/ | 09:10 |
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:11 |
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:12 |
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:13 |
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:14 |
jam | dimitern: "some tests don't generate valid ini files" doesn't sound like a good mix with nondeterministic ordering | 09:20 |
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:21 |
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:22 |
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:23 |
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:25 |
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:26 |
TheMue | dimitern: where to investigate next regarding networking? | 09:28 |
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:29 |
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:30 |
dooferlad | jam: No, ini files are not standardised. | 09:31 |
dimitern | TheMue, :) it's a long one let me warn you, but it does 99% of what's left around container addressability | 09:32 |
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:33 |
* dimitern well now! isn't this just beautiful: http://paste.ubuntu.com/10525017/ | 09:34 | |
dooferlad | dimitern: :-D | 09:35 |
TheMue | dimitern: ouch, neat, that looks cool | 09:35 |
dimitern | TheMue, dooferlad, there it is http://reviews.vapour.ws/r/1072/ | 09:42 |
TheMue | *click* | 09:43 |
* dimitern looks at the diff, which is slightly shy of 1000 lines | 09:43 | |
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:45 |
dooferlad | dimitern: you are the reason why http://www.internetslang.com/ exists :-) | 09:46 |
dimitern | dooferlad, I knew it :) | 09:47 |
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:50 |
dimitern | axw, it does, doesn't it? :) and here's the one for maas: http://paste.ubuntu.com/10525174/ | 09:51 |
dimitern | (some stuff needs ironing out it seems) | 09:52 |
axw | very cool, glad to see it come to fruition | 09:54 |
dimitern | :) thanks axw | 09:57 |
dimitern | dooferlad, TheMue, I'm omw in ~2m | 10:00 |
TheMue | kk | 10:00 |
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:05 |
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:33 |
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:41 |
wallyworld | natefinch: it's on oil so maybe a deployment or setup issue? | 10:42 |
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:45 |
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:46 |
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:47 |
* perrito666 imagines getting paper notes with rpc calls every couple of seconds | 10:48 | |
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:49 |
wallyworld | perrito666: yeah, it may pay to ping jason on irc to ask some questions about their set up | 10:50 |
natefinch | I'm assuming any comments on that bug from earlier than this month are unrelated | 10:51 |
perrito666 | you might notice in the logs that all credentials are empty in the dial info | 10:57 |
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 | 10:58 |
mup | Bug #1428074 was filed: api/networker and apiserver/networker tests fail <juju-core:New> <https://launchpad.net/bugs/1428074> | 11:05 |
mup | Bug #1428074 changed: api/networker and apiserver/networker tests fail <juju-core:New> <https://launchpad.net/bugs/1428074> | 11:06 |
mup | Bug #1428074 was filed: api/networker and apiserver/networker tests fail <juju-core:New> <https://launchpad.net/bugs/1428074> | 11:16 |
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:17 |
TheMue | dimitern: you've got a review | 11:24 |
dimitern | TheMue, thanks! | 11:24 |
TheMue | dimitern: yw | 11:24 |
TheMue | aaargh, once again a map ordering issue | 11:28 |
tasdomas | dimitern, re the bug I filed - I can still reproduce it using go 1.2.1 (built from source) | 11:36 |
dimitern | tasdomas, oh really? that's worse than I though then | 11:37 |
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:38 |
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:39 |
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:40 |
dimitern | wallyworld, I was not aware of that decision (about map ordering issues needing to be no less than high) | 11:41 |
dimitern | tasdomas, I can't reproduce it with 1.2.1 gccgo, which means it's not a map ordering issue then | 11:42 |
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:43 |
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:44 |
wallyworld | when we upgrade go toolchain | 11:45 |
dimitern | wallyworld, +1 that sgtm | 11:45 |
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:46 |
tasdomas | dimitern, ack | 11:47 |
dimitern | dooferlad, have you pushed the changes? | 11:52 |
dooferlad | dimitern: just doing so now | 11:52 |
dimitern | ok | 11:52 |
dooferlad | dimitern: pushed | 11:53 |
dooferlad | dimitern: https://github.com/juju/testing/compare/master...dooferlad:master-deref is the testing branch change | 11:53 |
dooferlad | dimitern: Oh, and I need to remove the change to dependencies.tsv. That will arrive shortly. | 11:54 |
dimitern | dooferlad, can you expand a bit why the Indirect was needed? | 11:55 |
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:57 |
dimitern | dooferlad, ok, great | 11:58 |
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 | 11:59 |
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:00 |
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:02 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
anastasiamac | dimitern: tyvm :D | 12:19 |
dimitern | TheMue, btw here's the PR with megawatcher tests I was talking about - https://github.com/juju/juju/pull/1588/files | 12:25 |
TheMue | dimitern: ah, great, just creating a card for it | 12:26 |
dimitern | TheMue, cheers! | 12:26 |
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:00 |
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> | 13:45 |
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:39 |
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:40 |
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:41 |
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:42 |
* dimitern steps out for ~30m | 14:48 | |
ericsnow | natefinch, wwitzel3: standup? | 15:05 |
=== kadams54 is now known as kadams54-away | ||
ericsnow | dooferlad: I've followed up on your review request | 15:32 |
ericsnow | dooferlad: thanks for tackling that | 15:32 |
ericsnow | dooferlad: what can I do to help get that landed today? | 15:33 |
=== kadams54-away is now known as kadams54 | ||
dooferlad | ericsnow: I just landed a change to juju/testing, which should be all I need now. | 15:34 |
dooferlad | ericsnow: just updating dependencies.tsv and re-testing | 15:35 |
ericsnow | dooferlad: you've already rebased/merged against master? | 15:35 |
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:36 |
katco | 0/?pli=1#inbox/who | 15:50 |
katco | lol oops | 15:50 |
mgz | #blameemacs | 15:52 |
katco | lol | 15:53 |
dimitern | mgz, hey there | 15:53 |
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:54 |
dimitern | mgz, | 15:55 |
dimitern | mgz, sorry, could you rephrase that a bit? :) | 15:55 |
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:57 |
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:58 |
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 | 15:59 |
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:00 |
ericsnow | fwereade: you free to meet? | 16:01 |
alexisb | dimitern, ping | 16:24 |
dimitern | alexisb, pong | 16:24 |
alexisb | hey there | 16:24 |
dimitern | hey, what's up? | 16:24 |
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:25 |
dimitern | I'll respond and ask for a bug report | 16:26 |
alexisb | thanks | 16:27 |
dimitern | np | 16:28 |
dimitern | tasdomas, 994 is reviewed | 16:40 |
dimitern | alexisb, replied | 16:41 |
alexisb | dimitern, saw it and thank you | 16:42 |
ericsnow | dooferlad: thanks for landing that! | 17:28 |
dooferlad | ericsnow: no worries! | 17:29 |
=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
=== kadams54 is now known as kadams54-away | ||
=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
=== kadams54 is now known as kadams54-away | ||
=== kadams54-away is now known as kadams54 | ||
tasdomas | dimitern, thanks | 20:47 |
* 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:11 |
perrito666 | thumper: that is almost not politically correct | 21:12 |
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:13 |
=== kadams54 is now known as kadams54-away | ||
natefinch | people that write unit tests which start web servers should be flogged | 21:16 |
perrito666 | natefinch: not everyone speaks unit tests as a first testing choice... :p | 21:17 |
natefinch | :p | 21:17 |
thumper | lol | 21:17 |
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:19 |
perrito666 | adding fields to status is a royal pain in the rear | 21:21 |
=== kadams54-away is now known as kadams54 | ||
ericsnow | menn0: FYI, I addressed your comments in and added tests to http://reviews.vapour.ws/r/1059/ | 21:41 |
menn0 | ericsnow: looking | 21:43 |
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:54 |
mwhudson | flag.StringVar rather | 21:55 |
menn0 | ericsnow: ship it with tiny fixes | 21:55 |
ericsnow | menn0: cool, thanks | 21:55 |
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:06 |
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:07 |
=== kadams54 is now known as kadams54-away | ||
perrito666 | here I was trying to fix my 4 broken tests... now I have 15 ... how did that happened | 22:13 |
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:14 |
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:15 |
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:16 |
thumper | anyone up for a quick review? http://reviews.vapour.ws/r/1076/diff/# | 22:23 |
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:25 |
ericsnow | thumper: I've posted a review (just 1 issue to resolve) | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!