| thumper | wallyworld_: I think the bot is wedged | 00:34 |
|---|---|---|
| wallyworld_ | ffs. ok | 00:34 |
| thumper | wallyworld_: trust yours to be picked up first | 00:56 |
| wallyworld_ | i know right :-D | 00:56 |
| thumper | WTF? | 00:57 |
| thumper | the bot won't land my branch because it had trouble loading the prereq | 00:57 |
| thumper | FFS | 00:57 |
| wallyworld_ | thumper: if it's any consolation, i updated golxc yesterday and last night had to patch the lxc stuff in juju core for it to compile, pending your stuff landing | 00:57 |
| thumper | wallyworld_: all you had to do was 'cd ~/go/src/launchpad.net/golxc; bzr revert -r 7' | 00:58 |
| thumper | and it would have been fine | 00:58 |
| wallyworld_ | yeah i know | 00:58 |
| === Tribaal_ is now known as Tribaal | ||
| wallyworld_ | was just trying to make you feel better | 00:58 |
| === _mup__ is now known as _mup_ | ||
| thumper | oh, ok | 01:00 |
| thumper | thanks | 01:00 |
| thumper | fuck yeah! | 01:05 |
| * thumper pokes around a bit | 01:06 | |
| thumper | hazmat: hey... | 01:08 |
| thumper | hazmat: wordpress works fine with aufs | 01:08 |
| thumper | hazmat: you had me all concerned about nothing | 01:08 |
| hazmat | thumper, hmm | 01:27 |
| thumper | hazmat: talked with hallyn about it | 01:28 |
| thumper | hazmat: he suggested to use aufs if btrfs doesn't work | 01:28 |
| thumper | hazmat: sorry, if not btrfs backed | 01:28 |
| thumper | hazmat: and shake out bugs :-) | 01:29 |
| thumper | but should all be good | 01:29 |
| hazmat | thumper, ah.. that's my issue.. i have btrfs under aufs | 01:29 |
| hazmat | thumper, cool.. glad thats resolved | 01:29 |
| thumper | so, fast and small for all \o/ | 01:29 |
| hazmat | thumper, so your able to install and relate wordpress to mysql? | 01:44 |
| hazmat | thumper, i always get this error on aufs on the db relation.. 2014-03-12 01:41:35 INFO db-relation-changed rm: fts_read failed: Stale NFS file handle | 01:44 |
| thumper | hazmat: yep, and looked at the web on 10.0.3.x | 01:44 |
| hazmat | thumper, cool | 01:44 |
| thumper | all good | 01:44 |
| davecheney | umm, ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju bootstrap -v --upload-tools | 01:50 |
| davecheney | Flag --verbose is deprecated with the current meaning, use --show-log | 01:50 |
| davecheney | 2014-03-12 01:50:08 WARNING juju.cmd.juju common.go:34 ignoring environments.yaml: using bootstrap config in file "/home/ubuntu/.juju/environments/local.jenv" | 01:50 |
| davecheney | 2014-03-12 01:50:08 ERROR juju.cmd supercommand.go:296 environment has no bootstrap configuration data | 01:50 |
| davecheney | this broke overnight | 01:50 |
| wallyworld_ | davecheney: i just tried bootstrapping local from trunk, seems to work | 02:13 |
| wallyworld_ | but i didn't have a jenv file lying around | 02:13 |
| wallyworld_ | i know that warning is new, but i don't know of any logic changes | 02:14 |
| davecheney | ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju status | 02:19 |
| davecheney | ERROR Unable to connect to environment "local". | 02:19 |
| davecheney | Please check your credentials or use 'juju bootstrap' to create a new environment. | 02:19 |
| davecheney | Error details: | 02:19 |
| davecheney | not bootstrapped | 02:19 |
| davecheney | environment is not bootstrapped | 02:19 |
| sinzui | davecheney, I can fix leankit | 02:25 |
| wallyworld_ | davecheney: you can try destroying your env and start again, that will clear any old jenv file | 02:27 |
| sinzui | davecheney, you were definitely deleted | 02:27 |
| sinzui | oh sweet, someone paid for more seats. There is not need to delete the old users | 02:28 |
| wallyworld_ | thumper: if you have a moment - https://codereview.appspot.com/74330044 | 02:35 |
| === Ursinha is now known as Ursinha-afk | ||
| wallyworld_ | thumper: you're not having much luck with your branch :-( | 02:39 |
| thumper | no... | 02:39 |
| === Ursinha-afk is now known as Ursinha | ||
| rick_h_ | anyone able to give me a hint on "BadRequest - The affinity group name is empty or was not specified." when deploying to azure. I've created a storage group in East US and that's the location set in my env.yaml | 03:25 |
| rick_h_ | ah, seems I'm hitting https://bugs.launchpad.net/juju-core/+bug/1259350 | 03:28 |
| _mup_ | Bug #1259350: juju bootstrap fails in Azure (BadRequest - The affinity group name is empty or was not specified.) <azure-provider> <bootstrap> <juju-core:Triaged> <https://launchpad.net/bugs/1259350> | 03:28 |
| davecheney | https://bugs.launchpad.net/juju-core/+bug/1291165 | 03:33 |
| _mup_ | Bug #1291165: juju bootstrap local cannot bootstrap <ppc64el> <juju-core:Triaged> <https://launchpad.net/bugs/1291165> | 03:33 |
| davecheney | this has proved hard to unfuck | 03:33 |
| wallyworld_ | can you try removing the jenv file? | 03:35 |
| davecheney | ubuntu@winton-02:~/src/launchpad.net/juju-core$ cat /home/ubuntu/.juju/environments/local.jenv | 03:41 |
| davecheney | ubuntu@winton-02:~/src/launchpad.net/juju-core$ file /home/ubuntu/.juju/environments/local.jenv | 03:41 |
| davecheney | /home/ubuntu/.juju/environments/local.jenv: empty | 03:41 |
| davecheney | brilliant | 03:41 |
| davecheney | wallyworld_: yup, that fixed it | 03:42 |
| wallyworld_ | davecheney: i would have hoped destroy-env would have been able to do that | 03:42 |
| wallyworld_ | maybe it can't handle an empty file | 03:43 |
| davecheney | that sounds like a good resolution to the bug | 03:47 |
| davecheney | --force should remove the .jenv, with prejudice | 03:47 |
| davecheney | otherwise CTS will shank us | 03:47 |
| axw | wallyworld_: when you have a moment, please: https://code.launchpad.net/~axwalk/gwacl/deleteservice-media/+merge/210534 | 04:03 |
| wallyworld_ | sure | 04:03 |
| wallyworld_ | axw: are you going to delete the obsolete delete code? | 04:06 |
| wallyworld_ | in juju | 04:06 |
| axw | wallyworld_: I am going to in my new implementation | 04:07 |
| wallyworld_ | great | 04:07 |
| axw | wallyworld_: actually, DestroyHostedService is in gwacl | 04:07 |
| axw | which is what does all this manually | 04:07 |
| axw | I will remove it once the Juju side is updated | 04:07 |
| wallyworld_ | do maybe add to your branch | 04:07 |
| wallyworld_ | ok | 04:07 |
| * thumper is starting to get real fucked off with the landing bot | 04:26 | |
| thumper | no... | 04:26 |
| thumper | getting fucked off at that intermittent failing test | 04:26 |
| thumper | that fails more often than not | 04:27 |
| thumper | wallyworld_: you'll be happy to know that I came up with some good tests for this new code :) | 04:33 |
| * thumper is pretty happy with them | 04:33 | |
| wallyworld_ | great | 04:33 |
| thumper | just running 'make check' before proposing | 04:33 |
| wallyworld_ | ok | 04:33 |
| * thumper waits with baited breath to see if the fucking test fails again | 04:36 | |
| * wallyworld_ gets the popcorn | 04:40 | |
| thumper | GRRRR!!!! | 04:42 |
| * thumper approves again | 04:42 | |
| thumper | I think this branch is almost a record | 04:42 |
| * thumper taps his fingers... | 04:58 | |
| * thumper approves it again | 05:03 | |
| thumper | wallyworld_: https://codereview.appspot.com/74370044 if you have time | 05:03 |
| wallyworld_ | ok | 05:03 |
| * thumper wanders off for a bit | 05:03 | |
| thumper | will check on the bot in about 20 minutes | 05:03 |
| === thumper is now known as thumper-afk | ||
| jam1 | thumper-afk: I think the bot has been failing because it failed enough to start running out of disk space | 05:45 |
| jam1 | at least, it was at 6 out of 8GB consumed | 05:45 |
| === jam1 is now known as jam | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| thumper-afk | :( | 06:56 |
| thumper-afk | jam: can I get you to email me the bot creds again? or point me to where to get them from? | 06:57 |
| thumper-afk | that way I can look myself instead of annoying wallyworld_ | 06:57 |
| jam | thumper-afk: sure, though I'm poking at it right now myself | 06:57 |
| thumper-afk | thanks in advance | 06:57 |
| axw | thumper-afk: FYI, just found this: https://bugs.launchpad.net/juju-core/+bug/1291207 | 06:57 |
| jam | I'm trying to sort out the failures | 06:57 |
| _mup_ | Bug #1291207: juju-run symlink is broken after upgrade-juju <run> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1291207> | 06:57 |
| thumper-afk | :-( | 06:57 |
| thumper-afk | will look tomorrow (most likely | 06:58 |
| axw | looks like it'll be easy to fix. | 06:58 |
| wallyworld_ | thumper-afk: you hold the record | 06:58 |
| thumper-afk | fcking permissions | 06:58 |
| thumper-afk | wallyworld_: for annoying you? | 06:58 |
| thumper-afk | \o/ | 06:58 |
| wallyworld_ | that too :-) | 06:58 |
| === thumper-afk is now known as thumper | ||
| wallyworld_ | i mean for failed landing attempts | 06:58 |
| jam | thumper-afk: I have to sort out the original creds for nova list, but for now the IP address is 10.55.61.118 and your launchpad SSH keys can log in as 'ubuntu' | 06:59 |
| thumper | I'm going to sign off now, but I'll keep poking the landing bot | 06:59 |
| thumper | kk | 06:59 |
| thumper | ta | 06:59 |
| jam | bot is in limbo right now while I debug | 06:59 |
| thumper | kk | 06:59 |
| dimitern | rogpeppe, hey | 09:14 |
| rogpeppe | dimitern: yo! | 09:14 |
| dimitern | rogpeppe, I decided to drop one of the incomplete fixes - the one about .jenv detection | 09:14 |
| rogpeppe | dimitern: sounds like a good plan - it needed some more work | 09:15 |
| dimitern | rogpeppe, after rummaging for a while in the code I realized you're right and it deserves its own CL as it'll blow up this out of proportion | 09:15 |
| dimitern | rogpeppe, re registering a file:// protocol on utils/http by default | 09:30 |
| dimitern | rogpeppe, it seems the manual provider is using "file:///var/lib/juju/storage/tools.tar.gz" in the provider-state-url file when provisioning | 09:30 |
| dimitern | rogpeppe, and without that it fails to fetch the provider-state and claims it's not bootstrapped | 09:31 |
| dimitern | rogpeppe, (or something similar - i'm testing again now to see if that's the case) | 09:31 |
| rogpeppe | dimitern: how does it manage to work currently? | 09:31 |
| dimitern | rogpeppe, it's quite fragile in my experience | 09:32 |
| rogpeppe | dimitern: but how can it work at all if the file protocol isn't registered? | 09:33 |
| dimitern | rogpeppe, i had to set up a vm with "ubuntu" user to make it work for example - it was always trying ubuntu@bootstrap-host and it was failing to use the bootstrap-user i specified | 09:33 |
| dimitern | rogpeppe, well, that's the thing - simplestreams *does* register the file:// protocol for testing purposes | 09:33 |
| dimitern | rogpeppe, in some init() func | 09:33 |
| rogpeppe | dimitern: this isn't testing code though, is it? | 09:34 |
| dimitern | rogpeppe, but that code path doesn't seem to run in some cases | 09:34 |
| dimitern | rogpeppe, no it's production code | 09:34 |
| dimitern | rogpeppe, simplestreams.go:379 | 09:35 |
| rogpeppe | dimitern: in which dir? | 09:35 |
| dimitern | rogpeppe, envs/ss/ | 09:35 |
| dimitern | rogpeppe, but since RegisterProtocol there uses http.DefaultTransport it wasn't working when ssl-hostname-validation was set to false (and a non-validating tls transport was used) | 09:36 |
| rogpeppe | dimitern: hmm, i start to see | 09:36 |
| wwitzel3 | rogpeppe: what is the command you want tested for 512-maas-bootstrap-bridge-utils? | 09:38 |
| dimitern | rogpeppe, I'll run a series of tests of manual bootstrap and local bootstrap + manual provisioning to before reproposing without the file:// proto registration | 09:38 |
| rogpeppe | wwitzel3: we need to check that we can deploy units to the bootstrap node and that we can connect to those units | 09:39 |
| rogpeppe | dimitern: the fact that simplestreams is registering the file protocol seems a bit wrong. i need to think about it for a little bit. | 09:40 |
| dimitern | rogpeppe, it *definitely* seems wrong like this, unconditionally | 09:40 |
| wwitzel3 | rogpeppe: ok, I'm on your branch and I've bootstraped a node in my maas .. so I can just deploy anything? | 09:41 |
| rogpeppe | wwitzel3: try: juju deploy --to lxc:0 ubuntu | 09:41 |
| wwitzel3 | rogpeppe: ok, got it, when I "fixed" the lxc not being installed from cloud-tools before, I was testing not using --upload-tools. So my fix actually wasn't a fix and broke the CI build. | 09:49 |
| rogpeppe | wwitzel3: good point | 09:50 |
| wwitzel3 | rogpeppe: so I'm actually fixing it now :P .. and I will test your branch with that test. | 09:51 |
| rogpeppe | wwitzel3: thanks | 09:51 |
| wwitzel3 | rogpeppe: I also managed to get my maas configured in such away that I can easily destroy environ without having to rebuild the nodes from scratch. By snapshotting them at the right time, I can just restore to the snapshot. | 09:52 |
| wwitzel3 | rogpeppe: so testing is a lot faster now :) | 09:52 |
| rogpeppe | wwitzel3: nice | 09:52 |
| dimitern | rogpeppe, so without the file:// proto registration I get this: | 10:17 |
| dimitern | rogpeppe, 2014-03-14 08:04:54 ERROR juju.cmd supercommand.go:296 cannot load state from URL "file:///var/lib/juju/storage/provider-state" (read from "/tmp/provider-state-url"): Get file:///var/lib/juju/storage/provider-state: unsupported protocol scheme "file" | 10:17 |
| dimitern | rogpeppe, with manual bootstrap | 10:17 |
| dimitern | rogpeppe, if you're against registering a file protocol handler, I can check for file:// schema in the environs/bootstrap LoadStateFromURL() and try to read it directly instead | 10:20 |
| rogpeppe | dimitern: i'm still trying to think it through | 10:20 |
| rogpeppe | dimitern: the thing that makes me most uncomfortable is the disconnected nature of the fix here - we have two places a long way apart in the code (utils/http vs environs/simplestreams) that are both intimately connected - that feels pretty sleazy | 10:24 |
| dimitern | rogpeppe, it does, doesn't it | 10:24 |
| rogpeppe | dimitern: i'd be happier if everything used a Client from utils/http | 10:25 |
| rogpeppe | dimitern: then we could have a function to register schemes in there, rather than using http.DefaultClient | 10:25 |
| dimitern | rogpeppe, in fact this error only seems to happen when you manual bootstrap with ssl-hostname-verification: false, tested just now | 10:25 |
| dimitern | rogpeppe, and that's due to simplestreams | 10:25 |
| rogpeppe | dimitern: that sounds right - if ssl-hostname-verification is true, we use http.DefaultClient | 10:25 |
| dimitern | rogpeppe, so I'll drop the file:// proto registration for this CL and file a bug about unifying http clients | 10:26 |
| rogpeppe | dimitern: doesn't that leave trunk broken? | 10:26 |
| rogpeppe | dimitern: i guess it's already broken though | 10:26 |
| dimitern | rogpeppe, yeah - it's no more broken than it was | 10:28 |
| voidspace | rogpeppe: in juju-core/instance/instance.go where is Address defined? | 10:31 |
| voidspace | is it a built-in type | 10:31 |
| rogpeppe | voidspace: in instance/address.go | 10:32 |
| voidspace | ah, same package name | 10:32 |
| voidspace | just not the same file | 10:32 |
| rogpeppe | voidspace: if in doubt, grep for 'type Foo' | 10:32 |
| voidspace | gd doesn't work on my desktop machine either | 10:32 |
| voidspace | must work out why | 10:32 |
| rogpeppe | voidspace: yeah - i find it invaluable | 10:33 |
| rogpeppe | voidspace: you could find out if it works ok just running it from the command line | 10:33 |
| voidspace | rogpeppe: right, good call | 10:33 |
| rogpeppe | voidspace: the only built-in types are mentioned here: http://golang.org/ref/spec#Predeclared_identifiers | 10:36 |
| voidspace | rogpeppe: yeah, I just went there to check :-) | 10:36 |
| voidspace | thanks | 10:36 |
| rogpeppe | voidspace: (which is the definitive list of predeclared identifiers) | 10:36 |
| rogpeppe | voidspace: if you haven't already, the spec is well worth a read | 10:36 |
| rogpeppe | voidspace: being unusually readable for such things | 10:37 |
| voidspace | rogpeppe: right, I haven't | 10:40 |
| voidspace | rogpeppe: ok, so my godef wasn't properly installed in vim (the bundle wasn't working - I've now manually installed godef.vim) | 10:40 |
| voidspace | rogpeppe: so now it is not working in much more interesting and potentially fixable ways... :-) | 10:41 |
| rogpeppe | voidspace: lol | 10:41 |
| voidspace | rogpeppe: it only looked like it was sort of working because "gd" is the default vim "goto local definition" vim command anyway | 10:41 |
| rogpeppe | voidspace: so how's it failing now? | 10:41 |
| voidspace | For example | 10:42 |
| voidspace | parseLocalPackage error: no more package files found^@godef: no declaration found for Address | 10:42 |
| rogpeppe | voidspace: that ^@godef thing is weird | 10:42 |
| voidspace | rogpeppe: yeah, I'd better check godef.vim I guess | 10:44 |
| rogpeppe | voidspace: godef has got a -debug flag, which might or not produce some useful info in this case | 10:44 |
| voidspace | godef --help is "terse" | 10:45 |
| voidspace | and [flags] expr does not explain the arguments it takes *particularly* well | 10:46 |
| dimitern | rogpeppe, filed bug 1291292 | 10:46 |
| _mup_ | Bug #1291292: use a utils/http client for all HTTP(S) calls across the codebase <manual-provider> <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1291292> | 10:46 |
| rogpeppe | voidspace: yeah, could do better :-) | 10:47 |
| rogpeppe | voidspace: "expr" is a go expression | 10:47 |
| voidspace | rogpeppe: so I did "godef instance.Address" | 10:47 |
| voidspace | and got | 10:47 |
| voidspace | godef: cannot read : open : no such file or directory | 10:47 |
| rogpeppe | voidspace: try: godef -f somefile.go instance.Address | 10:48 |
| voidspace | rogpeppe: cool, thanks | 10:48 |
| rogpeppe | voidspace: where somefile.go is the file you're going from | 10:48 |
| voidspace | right | 10:48 |
| rogpeppe | voidspace: standup: https://plus.google.com/hangouts/_/canonical.com/juju-core?v=1394218410 | 10:48 |
| voidspace | rogpeppe: and it works | 10:49 |
| voidspace | hmmm.... | 10:49 |
| rogpeppe | voidspace: hmm | 10:49 |
| voidspace | rogpeppe: which is good news, just need to figure out the vim integration | 10:49 |
| rogpeppe | voidspace: yeah | 10:49 |
| dimitern | jam, mgz_, standup? | 10:50 |
| mgz_ | I'm here | 10:50 |
| voidspace | rogpeppe: is this the canonical vim-godef? https://github.com/dgryski/vim-godef | 10:56 |
| rogpeppe | voidspace: i think so | 10:56 |
| voidspace | rogpeppe: thanks | 10:56 |
| voidspace | rogpeppe: if I start vim from the launchpad.net directory it works - so it's not coping with shorter relative paths I think | 11:02 |
| rogpeppe | voidspace: interesting | 11:02 |
| voidspace | rogpeppe: if I start vim from launchpad.net/juju-core/worker (for example) it fails | 11:02 |
| voidspace | rogpeppe: so yay, it works! :-) | 11:03 |
| rogpeppe | voidspace:cool | 11:03 |
| voidspace | rogpeppe: hmmm... maybe not, it works once and then the next call doesn't work :-/ odd | 11:09 |
| rogpeppe | voidspace: i'd add some debug prints to the source | 11:10 |
| rogpeppe | voidspace: see what arguments are actually being passed | 11:10 |
| voidspace | rogpeppe: ok, outside work time I think | 11:10 |
| rogpeppe | voidspace: then try calling godef directly with those arguments and see if you can repro the failure | 11:10 |
| rogpeppe | voidspace: probsa | 11:10 |
| voidspace | rogpeppe: my guess is that it's mainly a path issue | 11:11 |
| rogpeppe | voidspace: it may well be | 11:11 |
| dimitern | rogpeppe, last look over https://codereview.appspot.com/72860045/ before i land it? | 11:22 |
| rogpeppe | dimitern: will do | 11:22 |
| jam | vladk: It would seem that you made it to IRC, am I chatting to the right vlad ? | 11:39 |
| vladk | yes | 11:39 |
| voidspace | mgz_: so I need coffee and then we should talk | 11:40 |
| mgz_ | voidspace: me too | 11:41 |
| jam | vladk: welcome again to the team | 11:42 |
| jam | natefinch: FWIW my last round of "If we get EOF, Refresh + Ping" seems to have landed cleanly, and allowed thumper's branch to land | 11:43 |
| jam | it is possible that the fix was that I now *always* call Ping after replSetReconfig | 11:43 |
| jam | to detect if we're actually going to get an EOF | 11:43 |
| jam | that would otherwise have been missed | 11:43 |
| jam | and then Refresh() and Ping again | 11:43 |
| jam | natefinch: I'm not sure, but hey, 2 branches landed back to back is great news for thebot | 11:44 |
| dimitern | so ever since we decided to shorten the standup to 15m it started getting 30-45m each time :) | 11:50 |
| natefinch | jam: that's great. | 11:51 |
| natefinch | jam: that may have been the fix... there seems to be a lot of chicken waving in getting the replicaset stuff working correctly | 11:53 |
| jam | natefinch: given the "wait for us to wake up and be ready" it certainly does make you wave some chickens | 11:54 |
| dimitern | rogpeppe, should be good to land, right? | 11:54 |
| * rogpeppe remembers to go back and look | 11:55 | |
| rogpeppe | dimitern: i don't think DetectionScript and CheckProvisioned should be exported - they could be added to export_test.go so that local tests can access them | 11:56 |
| rogpeppe | dimitern: they aren't used in production code external to the package AFAICS | 11:57 |
| jam | if people here could Ping when they set an MP to approved, I'd like to keep an eye on the bot, it looks like it is semi-healthy again | 11:57 |
| wwitzel3 | so in the case where a var of a package is private, but I want to use it in a test, do I just make it public .. seems not what I want to do. | 12:07 |
| wwitzel3 | the var is a slice that is modified by the package I am testing and I want to assert that those modifications are successful | 12:08 |
| rogpeppe | wwitzel3: is the slice a global? | 12:09 |
| natefinch | wwitzel3: are you doing this from another package, or from inside the package with the slice? | 12:09 |
| wwitzel3 | rogpeppe, natefinch: the slice is a global, it is being modified from side the functions of a struct in the same package. | 12:12 |
| wwitzel3 | s/side/inside | 12:12 |
| rogpeppe | wwitzel3: in general I'm skeptical of functions that modify global state, but it may be ok in this instance | 12:12 |
| rogpeppe | wwitzel3: what does the slice hold? | 12:13 |
| wwitzel3 | rogpeppe: fair, this is the requirePackages slice in the lxc/initalisation.go | 12:13 |
| wwitzel3 | requiredPackages .. helps if I could type this morning | 12:13 |
| natefinch | wwitzel3: if your tests are in the same package as the slice, you can just modify it directly. THat is, put your tests in the same package (as opposed to <package>_test) and then you can access non-exported data | 12:14 |
| wwitzel3 | natefinch: Ok, and that is not taboo? | 12:14 |
| rogpeppe | wwitzel3: why does that slice need to be modified? | 12:14 |
| rogpeppe | wwitzel3: it's a judgement call | 12:14 |
| wwitzel3 | rogpeppe: so that --target-release is passed to the AptGetInstall that consumes the slice | 12:15 |
| natefinch | wwitzel3: it's not taboo, that's how you get nice limited-scope tests to verify specific behavior. | 12:15 |
| rogpeppe | wwitzel3: the other approach is to have an export_test.go file in the same package that exports some variables just for tests | 12:15 |
| wwitzel3 | rogpeppe: I like the export_test approach | 12:16 |
| natefinch | rogpeppe: export_test is an abomination... there seems to be no reason to do it other than "all the rest of my tests are external, and I don't want to make another file for internal tests" | 12:16 |
| wwitzel3 | natefinch: I like that it is explict | 12:16 |
| rogpeppe | natefinch: i wouldn't word it so strongly | 12:16 |
| rogpeppe | natefinch: there's a trade-off here | 12:17 |
| natefinch | rogpeppe: it just means that your tests now use something that looks public that doesn't actually exist in the real package | 12:17 |
| natefinch | rogpeppe: at least with internal tests, it's clear you're using package internals | 12:17 |
| wwitzel3 | natefinch: that's true | 12:17 |
| natefinch | rogpeppe: there's nothing that says you can't have both internal tests and external tests | 12:17 |
| natefinch | sorry, kids are up, I gotta go. I wanted to have this discussion last week, but it was too hard over the hangouts. | 12:18 |
| wwitzel3 | well it seems like there is less debate over just making the tests be part of the package, so I will go that route :) | 12:18 |
| rogpeppe | natefinch: with internal tests, you can't tell whether any call is public or private | 12:18 |
| wwitzel3 | and then people can pick on me in the code review | 12:18 |
| rogpeppe | wwitzel3: i think natefinch is about the only one with that particular view :-) | 12:18 |
| rogpeppe | wwitzel3: although i don't mind internal tests much either | 12:19 |
| wwitzel3 | rogpeppe: maybe so, but I have to pair with him today, so he wins :P | 12:19 |
| rogpeppe | wwitzel3: ha ha | 12:19 |
| rogpeppe | wwitzel3: BTW, i think that modifying the global slice is almost certainly the wrong approach in this case | 12:20 |
| dimitern | rogpeppe, agreed I changed that as you suggested | 12:20 |
| wwitzel3 | rogpeppe: yeah, I am actually going to send a different one instead of modifying | 12:20 |
| rogpeppe | dimitern: thanks | 12:20 |
| dimitern | rogpeppe, and I'm waiting for your LGTM | 12:20 |
| rogpeppe | dimitern: i'm presuming you haven't re-proposed the changes yet | 12:23 |
| voidspace | is it common when comparing two structs of the same type to get a runtime error "comparing uncomparable type" from c.Assert | 12:25 |
| voidspace | https://pastebin.canonical.com/106327/ | 12:25 |
| rogpeppe | dimitern: LGTM | 12:26 |
| rogpeppe | voidspace: you probably want to be using gc.DeepEquals | 12:26 |
| voidspace | rogpeppe: sounds good, thanks | 12:26 |
| rogpeppe | voidspace: not all types in Go are comparable | 12:27 |
| rogpeppe | voidspace: specifically, slices and function pointers aren't | 12:27 |
| voidspace | rogpeppe: but you can compare type and compare members | 12:27 |
| voidspace | rogpeppe: slices are uncomparable !? | 12:27 |
| voidspace | that's the issue | 12:27 |
| voidspace | DeepEquals is at least pointing me to the slices it can't compare | 12:28 |
| voidspace | runtime error: comparing uncomparable type []instance.Id | 12:28 |
| rogpeppe | voidspace: yes, slices are uncomparable because it's not clear how the comparison should work | 12:28 |
| voidspace | compare length and if they're the same length compare members are equal | 12:28 |
| rogpeppe | voidspace: there are at least three possible ways | 12:28 |
| voidspace | what other way would make sense? | 12:28 |
| rogpeppe | voidspace: slices also have additional values after the length | 12:29 |
| voidspace | capacity | 12:29 |
| rogpeppe | voidspace: yeah | 12:29 |
| voidspace | hmmm | 12:29 |
| rogpeppe | voidspace: and another possibility is to compare by pointer equality | 12:29 |
| voidspace | an identity check | 12:30 |
| rogpeppe | voidspace: yeah | 12:30 |
| voidspace | that's a different check in my opinion | 12:30 |
| rogpeppe | voidspace: it's not clear which one == should use though | 12:30 |
| rogpeppe | voidspace: if i compare two pointers, it doesn't compare their contents | 12:30 |
| voidspace | rogpeppe: that's an identity check not an equality check though right (using Python terminology) | 12:31 |
| rogpeppe | voidspace: there's no distinction between the two in Go currently | 12:31 |
| dimitern | rogpeppe, yeah, I wanted to address any comments with one proposal | 12:31 |
| dimitern | rogpeppe, thanks! | 12:32 |
| voidspace | rogpeppe: but the very idea of pointers introduces the distinction | 12:32 |
| rogpeppe | voidspace: and if we compare members recursively, there's the possibility that we might get an infinite loop in an equality check | 12:32 |
| voidspace | rogpeppe: only if you're equality implementation is dumb | 12:32 |
| voidspace | :-) | 12:32 |
| voidspace | rogpeppe: but yeah, maybe making arbitrary types automatically comparable is problematic | 12:33 |
| voidspace | rogpeppe: how do you work around it for tests? | 12:33 |
| rogpeppe | voidspace: DeepEquals | 12:33 |
| voidspace | rogpeppe: except that doesn't work for types with slices as members | 12:33 |
| rogpeppe | voidspace: sure it does | 12:33 |
| rogpeppe | voidspace: DeepEquals is recursive | 12:33 |
| voidspace | rogpeppe: hah | 12:33 |
| rogpeppe | voidspace: (and deals with cycles too) | 12:33 |
| voidspace | rogpeppe: the DeepEquals works | 12:33 |
| voidspace | rogpeppe: and the error I *now* have is from the next Assert | 12:34 |
| voidspace | I just didn't notice | 12:34 |
| voidspace | so DeepEquals is fine and I'll stop complaining :-) | 12:34 |
| rogpeppe | voidspace: if you use jc.DeepEquals (from testing/checkers) then it will tell you where the comparison failed too | 12:34 |
| voidspace | yep | 12:34 |
| rogpeppe | voidspace: which is great if you're comparing a large chunk of data | 12:34 |
| voidspace | I'm using gc.DeepEquals (from gocheck) and it is giving me enough information at the moment | 12:34 |
| voidspace | ah, but not the member name that failed, just the comparison that failed | 12:35 |
| rogpeppe | voidspace: yeah | 12:35 |
| voidspace | which for this type is sufficient as it only has two members | 12:35 |
| voidspace | rogpeppe: thanks | 12:35 |
| rogpeppe | voidspace: there's one other distinction between gocheck.DeepEquals (which uses reflect.DeepEqual) and checkers.DeepEquals - the former treats a nil slice as distinct from an empty slice; the latter does not. | 12:36 |
| rogpeppe | voidspace: since in general we treat a nil slice exactly the same as an empty slice, the latter can be useful | 12:36 |
| voidspace | rogpeppe: right, useful to know | 12:36 |
| dimitern | wallyworld_, still there? | 13:44 |
| wallyworld_ | sorta | 13:44 |
| dimitern | wallyworld_, so should i assign bug 1290684 to myself? | 13:44 |
| _mup_ | Bug #1290684: cannot perform multiple upgrades <upgrade-juju> <juju-core:In Progress by wallyworld> <https://launchpad.net/bugs/1290684> | 13:44 |
| wallyworld_ | i have a mp up for that bug | 13:44 |
| wallyworld_ | https://code.launchpad.net/~wallyworld/juju-core/old-agentconf-datadir/+merge/210526 | 13:45 |
| dimitern | wallyworld_, I can't see a linked branch | 13:45 |
| wallyworld_ | i haven't linked it sorry | 13:45 |
| wallyworld_ | will do so | 13:45 |
| dimitern | wallyworld_, ok, so after yours lands, I can file a separate bug about migrating Jobs in 1.18 config? | 13:46 |
| wallyworld_ | yeah, and anything else that need doing | 13:46 |
| wallyworld_ | maybe it's just Jobs | 13:46 |
| wallyworld_ | can't recall right now | 13:46 |
| wallyworld_ | before i and i just want to ensure local provider is covered | 13:47 |
| dimitern | sure | 13:47 |
| dimitern | I also have some comments on your CL | 13:47 |
| wallyworld_ | ok | 13:47 |
| wallyworld_ | i'm off to bed, i'll look tomorrow | 13:48 |
| jcastro | you guys ready for the UDS update? | 13:55 |
| natefinch | jcastro: glad you reminded me | 13:55 |
| jcastro | https://plus.google.com/hangouts/_/hoaevent/AP36tYdJ0WjYraULj4VVnIhg2-wan1zM_Q6nzudEY4WfC6p1-8aoWw?authuser=0&hl=en&hcb=0&lm1=1394632583536&hs=75&hso=0&heeid=tvJzNRrPTJA&ssc=WyIiLDAsbnVsbCxudWxsLG51bGwsW10sbnVsbCxudWxsLG51bGwsbnVsbCxudWxsLDc1LG51bGwsbnVsbCxudWxsLFsxMzk0NjMyNTgzNTM2XSxudWxsLFsiaG9hZXZlbnQiLCJBUDM2dFlkSjBXallyYVVMajRWVm5JaGcyLXdhbjF6TV9RNm56dWRFWTRXZkM2cDEtOGFvV3ciXSxbXSxudWxsLG51bGwsbnVsbCxudWxsLG51bGwsbnVsbCxudWxsLG5 | 13:56 |
| jcastro | 1bGwsbnVsbCxbMF0sW10sbnVsbCwidHZKek5SclBUSkEiLG51bGwsW10sbnVsbCxudWxsLG51bGwsW10sbnVsbCxudWxsLFtdXQ.. | 13:56 |
| jcastro | whoa! | 13:56 |
| jcastro | https://plus.google.com/hangouts/_/hoaevent/AP36tYdJ0WjYraULj4VVnIhg2-wan1zM_Q6nzudEY4WfC6p1-8aoWw?authuser=0&hl=en | 13:56 |
| jcastro | try that one | 13:56 |
| natefinch | rogpeppe, mgz_, dimitern, jam: what the hell have we delivered and do we intend to deliver? | 13:56 |
| natefinch | besides HA.... joyent provider, I guess | 13:57 |
| dimitern | natefinch, for 1.18? | 13:57 |
| natefinch | dimitern: uh sure, or trusty | 13:57 |
| dimitern | natefinch, for trusty definitely more than for 1.18 | 13:58 |
| dimitern | natefinch, for 1.18 mostly lots of critical/high bug fixes and regressions | 13:58 |
| natefinch | dimitern: trusty is probably what people will care about | 13:59 |
| dimitern | natefinch, well HA, container networking (somewhat - ec2 + maas and basic support at that) | 13:59 |
| dimitern | natefinch, joyent, smoother upgrades (preferably major version upgrades, but perhaps not schema upgrades) | 14:01 |
| === edu-afk_ is now known as edamato | ||
| dimitern | natefinch, and better versioning (1.2.3-b1, -rc1, etc.) | 14:03 |
| natefinch | cool | 14:03 |
| jcastro | #ubuntu-uds-servercloud-1 | 14:03 |
| rogpeppe | dammit, i missed the hangout | 14:36 |
| rogpeppe | hmm, this is worrying: http://paste.ubuntu.com/7079579/ | 14:38 |
| wwitzel3 | I joined it, then realized I probably joined it the wrong way | 14:38 |
| wwitzel3 | so I just sat with my mic and camera on mute hoping no one noticed | 14:39 |
| natefinch | haha | 14:46 |
| natefinch | wwitzel3: it's ok. I'm sure no one noticed :) | 14:46 |
| natefinch | wwitzel3: it's not like it was being recorded or anything ;) | 14:47 |
| wwitzel3 | natefinch: hah, thanks | 14:48 |
| natefinch | jcastro: (from juju help add-machine): juju add-machine ssh:user@10.10.0.3 (manually provisions a machine with ssh) | 14:52 |
| * rogpeppe goes for lunch | 14:53 | |
| jcastro | yeah, the thing is we should explain in the docs how to use that cleverly. | 14:53 |
| jcastro | I can add it. | 14:53 |
| natefinch | jcastro: absolutely | 14:53 |
| rogpeppe | my lunch will be slightly extended today, as the sun is out and i need some exercise. will work a bit later. | 14:54 |
| natefinch | rogpeppe: have fun! | 14:56 |
| wwitzel3 | natefinch: so, I run go install -v juju-core/... and then I bootstrap with --upload-tools , but it would appear I am still just using the standard install | 15:19 |
| natefinch | wwitzel3: is your GOPATH at the front of your path or the back? | 15:21 |
| wwitzel3 | i'm dumb, thanks | 15:21 |
| wwitzel3 | natefinch: I assume it should be at the back? | 15:24 |
| natefinch | wwitzel3: I put mine at the front | 15:25 |
| natefinch | wwitzel3: Go > all the things | 15:25 |
| natefinch | wwitzel3: also that way, stuff I build overrides stuff I install, which is usually what you expect | 15:26 |
| wwitzel3 | natefinch: right, ok | 15:26 |
| sinzui | dimitern, is bug 1291400 fallout from wallyworld_ 's fix for bug 1290684? | 15:30 |
| _mup_ | Bug #1291400: migrate 1.16 agent config to 1.18 properly (DataDir, Jobs, LogDir) <regression> <upgrade-juju> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1291400> | 15:30 |
| _mup_ | Bug #1290684: cannot perform multiple upgrades <upgrade-juju> <juju-core:Fix Committed by wallyworld> <https://launchpad.net/bugs/1290684> | 15:30 |
| dimitern | sinzui, it's a follow-up on his fix | 15:30 |
| sinzui | thank you dimitern | 15:30 |
| dimitern | sinzui, the local provider 1.16->1.18 broke, so I'm fixing that | 15:31 |
| sinzui | rogpeppe, when do you think your fix for bug 1271144 will be merged> | 15:32 |
| _mup_ | Bug #1271144: br0 not brought up by cloud-init script with MAAS provider <cloud-installer> <landscape> <local-provider> <lxc> <maas> <regression> <juju-core:In Progress by rogpeppe> <https://launchpad.net/bugs/1271144> | 15:32 |
| wwitzel3 | natefinch: yeah my local version is 1.17.5, my which command is pointing to the right binary and GOPATH is correct, but when I upload-tools the server is still using 1.17.4.1 | 15:36 |
| wwitzel3 | natefinch: oh nevermind, I found it, I had two GOBINs apparently | 15:38 |
| natefinch | wwitzel3: you don't need gobin set, actually. Go will figure it out as needed | 15:39 |
| natefinch | wwitzel3: the only environment setting I set manually for go is GOPATH | 15:40 |
| natefinch | wwitzel3: oh,and gomaxprocs, I guess, but that's more optional | 15:40 |
| === niemeyer_ is now known as niemeyer | ||
| frankban | juju-core devs: I am getting this error while trying to bootstrap an ec2 environment using 1.17.4-trusty-amd64: http://pastebin.ubuntu.com/7079940/ | 16:00 |
| natefinch | frankban: I think that's due to a bug we had in 1.17.4 when you have juju-mongod installed locally. | 16:03 |
| frankban | natefinch: juju-mongodb is installed indeed | 16:03 |
| frankban | natefinch: so, is this going to be solved in the next trusty release? | 16:04 |
| natefinch | frankban: if you rename it or remove it, it should fix things. | 16:04 |
| natefinch | frankban: yep | 16:04 |
| frankban | natefinch: so, that's installed as a dependency of juju-local. we changed quickstart to install juju-local in place of the specific packages (e.g. lxc, mongodb-server). I see two choices: 1) wait for the next quickstart release until trusty includes a fixed version that works well with juju-local or 2) make quickstart install mogodb-server before juju-local. The latter seems suboptimal. Do we have a prevision for wh | 16:10 |
| frankban | en 1.17.5 or 1.18 will be released? | 16:10 |
| natefinch | sinzui: 1.17.5 is passing CI, right? When is that getting released? | 16:14 |
| sinzui | natefinch, I wish I knew. We agreed to target bugs that block the release of 1.17.5 https://launchpad.net/juju-core/+milestone/1.17.5 | 16:15 |
| sinzui | but I we are not making progress on them | 16:15 |
| sinzui | I want to release 1.17.5 tomorrow. We might need 1.17.6 | 16:15 |
| sinzui | natefinch, r2410 looks good there is just one outstanding azure test | 16:17 |
| natefinch | frankban: ^^ That's the best I have. Tomorrow, I guess. Sorry about the broken bootstrap. Totally my fault. | 16:19 |
| frankban | natefinch: no problem, and thanks! | 16:20 |
| wwitzel3 | natefinch: so I got the --target-release being properly sent to the apt-get command, but exec isn't liking it for some reason? http://paste.ubuntu.com/7080227/ | 16:57 |
| wwitzel3 | natefinch: if I copy and paste the Running: line sans [ ] .. the command runs just fine | 16:58 |
| natefinch | wwitzel3: this is probably the problem: "--target-release precise-updates/cloud-tools lxc" you have to separate out the strings, you can't pass them as one string, otherwise the command treats them as one single argument that it doesn't understand | 17:01 |
| natefinch | wwitzel3: so like "--target-release", "precise-updates/cloud-tools", "lxc" | 17:01 |
| natefinch | wwitzel3: I think everyone makes that mistake when using go to execute commands. There's no shell parsing the arguments, they're just passed to the executable as-is, so it would see arg0 as "--target-release precise-updates/cloud-tools lxc" rather than seeing it as three separate arguments | 17:03 |
| niemeyer | Hey | 17:06 |
| niemeyer | How's the migration to GitHub going? | 17:06 |
| natefinch | niemeyer: slow | 17:06 |
| niemeyer | natefinch: Any dates settled yet? | 17:06 |
| natefinch | niemeyer: not at all. We moved a few packages there, but there's basically no timeline for getting juju-core over there at the moment. We'll have to set up a landing bot and stuff. I know Jam was looking into it, but we've had a lot on our plates, so it hasn't gotten too far. | 17:08 |
| niemeyer | natefinch: Thanks for the details | 17:08 |
| natefinch | niemeyer: welcome. Jam would have more details, since he's really the one who decided to take charge of it. | 17:09 |
| niemeyer | natefinch: You're still using lbox for rietveld reviews, right? | 17:09 |
| natefinch | niemeyer: while we're still on bazaar, yes. We're not really sure right now what we'd use when we move to github. | 17:10 |
| wwitzel3 | natefinch: thank you | 17:11 |
| niemeyer | natefinch: Hopefully it'll be unnecessary | 17:12 |
| natefinch | niemeyer: well, github's reviews are somewhere between terrible and nonexistent depending on your definition, so we'll probably need something for reviews outside github. And same for controlling branches landing. | 17:13 |
| niemeyer | natefinch: Not sure why you feel that way | 17:20 |
| niemeyer | natefinch: Can you point me to reviews you've done there which provided you with that feeling? | 17:20 |
| mgz_ | rogpeppe: what's the right thing to compare errgo errors in tests? as the errorWrapper objects have different identities | 17:21 |
| mgz_ | hm, seems Deeo | 17:24 |
| natefinch | niemeyer: there's no side by side diffs, which makes large diffs very difficult to understand. It sends one email per inline comment on the code. | 17:24 |
| mgz_ | *DeepEquals does work now | 17:24 |
| niemeyer | natefinch: Can you point me to reviews you've done there so I can have an idea? | 17:24 |
| natefinch | niemeyer: sure, one sec | 17:24 |
| natefinch | mgz_: errors.Cause(err) should return the underlying error that is what we used to return raw | 17:25 |
| natefinch | niemeyer: this isn't a review, just an example of a diff that is made a lot more difficult to read because it's not side by side: https://github.com/travis-ci/travis-ci.github.com/pull/437/files#diff-dca34899b9ea26aa8d1b388f6eab933dR5 | 17:27 |
| natefinch | niemeyer: the email thing I can't really show per se, but when doing this review, each time I put in a single minor comment, both roger and I received emails. I much prefer reitveld's approach where all the comments are mailed all at once, when the reviewer indicates they're done. https://github.com/juju/ratelimit/commit/78b2ece8f84a196d02c5b3505dd79cf1ba8d7702 | 17:29 |
| natefinch | niemeyer: believe me, I'd much rather use github for everything, so it's all in one place, but reviews are pretty important, and if the tool makes them significantly more painful, then I don't think it's a good tradeoff. | 17:29 |
| niemeyer | natefinch: Okay, I was specifically wondering about *your* reviews, so I understand where your frustration comes from | 17:30 |
| niemeyer | natefinch: This is just a unified and colored diff.. I've been reading the diff -u output for long enough to not to have any issues with those | 17:31 |
| natefinch | niemeyer: unified diffs make it hard to see subtle changes that are made glaringly obvious in a nice side by side diff. | 17:32 |
| niemeyer | natefinch: So, do you have any reviews you have done in GitHub you can point to so we can be on the same page? | 17:32 |
| natefinch | niemeyer: this is mostly true when multiple lines are changed at once, and grouped together. So if in the middle of three lines has a 2014 instead of a 2013, you can easily miss it in a unified diff | 17:32 |
| natefinch | niemeyer: No, I don't. | 17:33 |
| * rogpeppe is back from a rather-longer-than-intended bike ride | 17:34 | |
| natefinch | rogpeppe: welcome back. I'm jealous, it's still pretty frigid here. | 17:34 |
| rogpeppe | sinzui: we think we have a fix - we're working on trying to test it live before landing it | 17:35 |
| niemeyer | natefinch: So "github's reviews are somewhere between terrible and nonexistent depending on your definition" is based on the opinion of someone that has no reviews in GitHub? | 17:35 |
| sinzui | rogpeppe, great. | 17:35 |
| niemeyer | natefinch: Uh.. awkward :) | 17:35 |
| rogpeppe | sinzui: sinzui has a local maas setup which hopefully will be able to test the fix | 17:35 |
| natefinch | niemeyer: I don't need ot have done a lot of reviews on github to know that one email per comment is annoying, or that I dislike unified diffs :) | 17:36 |
| sinzui | rogpeppe, I wish I had a local mass setup. If I did, CI would use it. | 17:36 |
| natefinch | sinzui: get one. Seems crazy we don't have one for CI. How much can it cost, a few grand? | 17:37 |
| sinzui | I had one for 2 days, CI ran. | 17:37 |
| natefinch | niemeyer: I could live with the emails, but not having a side by side diff feels like going back in time 15 years for no reason. | 17:37 |
| wwitzel3 | niemeyer: I've reviewed plenty of things on github and not having side by side diffing makes it painful for large commits. The output of diff, unified or not, is intended to be consumed by programs. Not people. | 17:37 |
| rogpeppe | mgz_: to compare errgo errors, either compare the strings, or for equality | 17:37 |
| rogpeppe | mgz_: it was always wrong to compare errors.New errors with DeepEquals IMHO | 17:38 |
| sinzui | natefinch, I have been negotiating with the server team. they signal where to test and we run the tests there...but the tests are on future maas, not a released maas | 17:38 |
| wwitzel3 | rogpeppe: I can test you stuff right now if you want, I finally ironed out the --target-release for lxc stuff | 17:39 |
| sinzui | dimitern, Isn't bug 1282690 near completion. I see code was merged? | 17:39 |
| _mup_ | Bug #1282690: ensure joyent provider gets included in 1.18 release <joyent-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1282690> | 17:39 |
| rogpeppe | wwitzel3: that would be very useful if you could | 17:39 |
| niemeyer | wwitzel3: That's far from true. The output of diff is optimized so it can be understood.. if we were worried only about programs, we could do much better than diff. | 17:40 |
| dimitern | sinzui, looking | 17:41 |
| wwitzel3 | niemeyer: understood and for human consumption are very different | 17:41 |
| wwitzel3 | niemeyer: xml can be understood, it isn't intended for human consumption | 17:41 |
| niemeyer | wwitzel3: Understood by a human.. | 17:41 |
| niemeyer | No matter, such strong opinions of how something is terrible should hopefully not come from people that never used the tool. | 17:42 |
| niemeyer | This is unhelpful, and create some bias for the next time an opinion shows up.. | 17:42 |
| dimitern | sinzui, i can't say it can be closed, because joyent is still commented out in provider/all, so it's not enabled by default, and afaik there are other things yet to finish | 17:44 |
| dimitern | dstroppa, ^^ can you confirm please? | 17:44 |
| natefinch | niemeyer: How would you even define a review on github? They don't even really have such a thing. You comment on commits / pull requests. That's it. | 17:44 |
| sinzui | thank you dimitern | 17:44 |
| wwitzel3 | niemeyer: consumption assumes usage, not just understanding .. anyway, if it had side by side diffs and some better keyboard shortcuts, I'd be happy enough with it. | 17:44 |
| niemeyer | natefinch: Please try to use it, then complain. | 17:45 |
| dstroppa | dimitern, sinzui: still not closed, but getting closer to completion | 17:46 |
| natefinch | niemeyer: I was complaining about the diffs, which I have used quite a bit. I even gave you an example that I felt showed how unified diffs are bad. The emails thing is easy to extrapolate into the future. | 17:46 |
| wwitzel3 | rogpeppe: you want to hangout and run through this together? | 17:46 |
| rogpeppe | wwitzel3: sure | 17:46 |
| rogpeppe | wwitzel3: https://plus.google.com/hangouts/_/canonical.com/juju-core | 17:47 |
| niemeyer | <natefinch> niemeyer: well, github's reviews are somewhere between terrible and nonexistent depending on your definition | 17:48 |
| natefinch | niemeyer: Yes. I think email notifications and diffs are integral to a review system. | 17:49 |
| jam | fkom | 17:52 |
| niemeyer | natefinch: I think it could be much better, but I'd rather debate that with someone that has used it at all. | 17:53 |
| natefinch | niemeyer: I've used it for two reviews. The things I complained about aren't going to change if I do 200 more reviews. Feel free to find someone else who has done more reviews to talk to. | 18:04 |
| voidspace | https://codereview.appspot.com/74900044 | 18:17 |
| wwitzel3 | https://codereview.appspot.com/72270044 | 18:20 |
| natefinch | voidspace: looking | 18:22 |
| voidspace | natefinch: thanks | 18:23 |
| bodie_ | what happens if the state service and the real service layer diverge? e.g. a network outage in a datacenter or node | 18:29 |
| bodie_ | maybe I'm misunderstanding it a bit as a state map where it's more a system for choreographing a service network and then deploying it | 18:33 |
| natefinch | bodie_: not really sure what you're asking. The state server checks on the status of the system continuously to see if machines are up. Are you asking what happens if the state server can't contact a deployed machine, but that machine is still up and healthy? | 18:35 |
| bodie_ | well, let's say it goes dark for whatever reason. so the state service DOES track the state of active nodes | 18:35 |
| bodie_ | like, let's say I'm running Riak, where if a single node goes offline it's not a big deal, but I probably want to replace it when I can | 18:36 |
| bodie_ | I'm just trying to map out in my head how the flow for that situation would look | 18:36 |
| natefinch | bodie_: the juju state server will bring up a replacement unit when it sees one is down | 18:40 |
| bodie_ | is that in mainline? | 18:42 |
| bodie_ | I'm asking around in a few places to get my bearings here before muscling into core, according to marco it doesn't respond but does see the outage | 18:42 |
| voidspace | natefinch: going running, if you leave any comments on the mp I'll see them when I return | 18:43 |
| natefinch | voidspace: cool | 18:43 |
| voidspace | there is some small chance that tomorrow I will be ubuntu native | 18:43 |
| voidspace | my PC build is "in progress" | 18:43 |
| natefinch | voidspace: woo hoo | 18:43 |
| bodie_ | :D | 18:43 |
| voidspace | it's "put everything in the case" time, followed by install ubuntu | 18:43 |
| voidspace | followed by "debug driver issues"... | 18:43 |
| voidspace | :-) | 18:43 |
| bodie_ | I just switched over from Debian last night.... so much cleaner to get rolling with juju, sadly | 18:43 |
| * rogpeppe looks for a feather to put in voidspace's headband | 18:44 | |
| voidspace | rogpeppe: I feel more like the cowboy than the indian... | 18:44 |
| voidspace | to be fair, with 13.10, which is on kernel > 3.10, everything *should* be fine | 18:45 |
| voidspace | at least until I try with three monitors ;-) | 18:45 |
| natefinch | bodie_: sorry, I'm wrong. It doesn't automatically bring up replacements. You'd have to do a juju status to see that one was down, and then juju deploy a replacement. | 18:45 |
| bodie_ | Gotcha | 18:45 |
| === edamato is now known as edu-afk | ||
| bodie_ | good to know ^^ | 18:45 |
| bodie_ | I bet some really interesting charms could be put together with custom software to do things like that | 18:46 |
| voidspace | although I do only have one ethernet cable upstairs - so I either to add another router (sounds like a recipe for pain with double NAT?) or go wireless on one of the machines | 18:46 |
| voidspace | we'll see I guess | 18:46 |
| natefinch | voidspace: can't you just use a switch? | 18:46 |
| voidspace | natefinch: I have a router and not a switch | 18:47 |
| voidspace | I don't *think* I have a switch | 18:47 |
| voidspace | have to check my bits boxes | 18:47 |
| voidspace | if I only have to go wireless for a day or two and I order one in it wouldn't be the end of the world | 18:47 |
| natefinch | voidspace: 4 port switches are pretty cheap these days | 18:47 |
| voidspace | natefinch: yeah | 18:47 |
| voidspace | natefinch: some routers can be reconfigured as switches too | 18:47 |
| voidspace | natefinch: I'll have to see what I've got | 18:47 |
| wwitzel3 | rogpeppe: http://paste.ubuntu.com/7080846/ it seems to have worked | 18:54 |
| wwitzel3 | bbiab | 18:54 |
| rogpeppe | wwitzel3: you need to try: juju add-unit --to lxc:2 ubuntu | 18:54 |
| wwitzel3 | rogpeppe: ok, running that now then | 18:55 |
| wwitzel3 | rogpeppe: I can ssh to the 2/lxc/0 container | 19:02 |
| rogpeppe | wwitzel3: brilliant | 19:02 |
| rogpeppe | wwitzel3: if you can do the negative checks on trunk, then we'll be good to land it | 19:03 |
| wwitzel3 | rogpeppe: yep, will do that then | 19:04 |
| rogpeppe | wwitzel3: thanks | 19:04 |
| natefinch | o/ thumper | 19:32 |
| thumper | hi natefinch | 19:32 |
| * thumper looks around for the power supply | 19:32 | |
| natefinch | thumper: could make for a short day | 19:32 |
| thumper | found it | 19:36 |
| voidspace | so I'm EOD | 19:44 |
| voidspace | g'night all | 19:44 |
| rogpeppe | thumper: hiya | 19:49 |
| thumper | o/ rogpeppe | 19:56 |
| thumper | hmm... no fwereade | 19:56 |
| natefinch | thumper: I think he's out until tomrorow | 19:56 |
| thumper | rogpeppe, natefinch: I don't suppose either of you know the progress that william has around removing git from the charm process? | 19:57 |
| rogpeppe | thumper: he seemed to be making good progress last week, but i don't know where he ended up | 19:57 |
| * thumper nods | 19:57 | |
| thumper | hmm... | 20:01 |
| thumper | seems our gobot is no longer doing the right think with new deps | 20:01 |
| * thumper bumped the dependency on golxc and the bot didn't update it | 20:01 | |
| * thumper goes to look... | 20:02 | |
| === arosales_ is now known as arosales | ||
| * rogpeppe is done | 20:50 | |
| rogpeppe | g'night all | 20:50 |
| thumper | damn... | 21:17 |
| thumper | rogpeppe: don't suppose you are still here? | 21:18 |
| thumper | natefinch: ping | 21:19 |
| natefinch | thumper: sorta, what's up? | 21:23 |
| thumper | natefinch: the bot has stopped updating dependencies | 21:24 |
| natefinch | thumper: I blame mgz_ | 21:24 |
| thumper | I vaguely remember that it should now be done with juju | 21:24 |
| thumper | but I don't have the creds... | 21:24 |
| thumper | and it seems dumb | 21:24 |
| natefinch | thumper: me neither | 21:24 |
| thumper | go get -u only brings in new deps | 21:24 |
| thumper | how do I get go to update what it has? | 21:25 |
| natefinch | thumper: go get -u should update what's there too, I think | 21:26 |
| thumper | natefinch: not according to the help | 21:26 |
| thumper | The -u flag instructs get to use the network to update the named packages | 21:26 |
| thumper | and their dependencies. By default, get uses the network to check out | 21:26 |
| thumper | missing packages but does not use it to look for updates to existing packages. | 21:26 |
| thumper | ah... | 21:27 |
| natefinch | thumper: isn't that what the -u is fir? | 21:27 |
| thumper | the by default bit | 21:27 |
| * thumper is dumb | 21:27 | |
| natefinch | thumper: ha | 21:27 |
| natefinch | thumper: ok, gotta go pick up thai food | 21:27 |
| thumper | kk | 21:27 |
| wallyworld_ | thumper: the bot never did update deps - it was always done by hand AFAIR. CI uses the dependencies file though | 21:49 |
| thumper | ah | 21:50 |
| thumper | bugger | 21:50 |
| wallyworld_ | yeah :-( | 21:50 |
| thumper | we should add it in then... | 21:50 |
| wallyworld_ | i wish Go used dep management | 21:50 |
| wallyworld_ | or had nice tooling for it | 21:50 |
| thumper | just use semantic versioning and all your problems go away * | 21:50 |
| wallyworld_ | sigh | 21:50 |
| * thumper does it manually | 21:55 | |
| thumper | hi fwereade | 21:56 |
| thumper | you really here? | 21:56 |
| thumper | wallyworld_: you fixed this, right? https://bugs.launchpad.net/juju-core/+bug/1291400 | 22:08 |
| _mup_ | Bug #1291400: migrate 1.16 agent config to 1.18 properly (DataDir, Jobs, LogDir) <regression> <upgrade-juju> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1291400> | 22:08 |
| wallyworld_ | thumper: yes, but there's more to do and dimiter is doing the rest | 22:08 |
| thumper | oh, more? | 22:08 |
| * thumper sighs | 22:08 | |
| wallyworld_ | i did datadir. but there's other new attrs like Jobs | 22:09 |
| wallyworld_ | and local provider is also a bit different | 22:09 |
| wallyworld_ | and dimiter did the 1.18 stuff originally so he's running with it | 22:09 |
| thumper | ok | 22:09 |
| bodie_ | anyone know what's causing this: src/launchpad.net/juju-core/charm/testing/mockstore.go:17:2: no buildable Go source files in /home/bodie/go/src/launchpad.net/gocheck | 22:35 |
| bodie_ | (when I go get launchpad.net/juju-core/... | 22:35 |
| bodie_ | nvm, looks like i'm good. just cleared it out and re-downloaded | 22:38 |
| jcw4 | anyone know about a type casting bug in the azure provider in juju-core? | 22:45 |
| jcw4 | conversion between gwacl.ConfigurationSet and gwacl.OSVirtualHardDisk | 22:46 |
| bodie_ | I think I'm getting something similar: http://pastebin.centos.org/8396/ | 22:53 |
| bodie_ | is this normal? | 22:55 |
| bodie_ | probably something to do with the ellipses | 23:00 |
| === cjohnston_ is now known as cjohnston | ||
| waigani | wallyworld_: you about? | 23:51 |
| wallyworld_ | yeeees? | 23:51 |
| waigani | hehe, can I annoy you? | 23:51 |
| wallyworld_ | yeeees? | 23:51 |
| waigani | just merged trunk got lots of test failures | 23:51 |
| wallyworld_ | did you update golxc | 23:52 |
| waigani | to do with lxc container stuff, so I switched to trunk and ran the tests again | 23:52 |
| waigani | ahhhh | 23:52 |
| waigani | no | 23:52 |
| waigani | I was going to say trunk fails as well, but that would explain it | 23:52 |
| wallyworld_ | go get -u launchpad.net/golxc | 23:52 |
| wallyworld_ | or something like that | 23:52 |
| waigani | yep, will to cheers | 23:52 |
| wallyworld_ | np. let me know if you have problems | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!