=== akhavr1 is now known as akhavr | ||
mup | Bug #1505460 opened: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460> | 01:07 |
---|---|---|
mup | Bug #1505460 changed: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460> | 01:10 |
mup | Bug #1505460 opened: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460> | 01:13 |
mup | Bug #1505460 changed: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460> | 01:16 |
mup | Bug #1505460 opened: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460> | 01:19 |
=== akhavr1 is now known as akhavr | ||
=== akhavr1 is now known as akhavr | ||
=== akhavr1 is now known as akhavr | ||
davecheney | Get:1 http://ports.ubuntu.com/ubuntu-ports/ trusty-updates/main linux-image-3.19.0-30-generic arm64 3.19.0-30.34~14.04.1 [51.2 MB] | 03:42 |
davecheney | 16% [1 linux-image-3.19.0-30-generic 10.0 MB/51.2 MB 20%] 56.8 kB/s 15min 1s^Z | 03:42 |
davecheney | wheee | 03:42 |
davecheney | cloud scale | 03:42 |
=== meetingology` is now known as meetingology | ||
=== urulama_ is now known as urulama | ||
mup | Bug #1505504 opened: error when destroying current environment in a multi-environment scenario <juju-core:New> <https://launchpad.net/bugs/1505504> | 05:23 |
=== akhavr1 is now known as akhavr | ||
mup | Bug #1505504 changed: error when destroying current environment in a multi-environment scenario <juju-core:New> <https://launchpad.net/bugs/1505504> | 05:32 |
mup | Bug #1505504 opened: error when destroying current environment in a multi-environment scenario <juju-core:New> <https://launchpad.net/bugs/1505504> | 05:47 |
=== akhavr1 is now known as akhavr | ||
rogpeppe | mgz: it looks like reviewboard has stopped adding the "Review request" comment to github PR titles | 06:57 |
rogpeppe | mgz: (i just had to add one manually to https://github.com/juju/juju/pull/3485 and the two before it haven't been labeled) | 06:57 |
=== akhavr1 is now known as akhavr | ||
=== akhavr1 is now known as akhavr | ||
=== akhavr1 is now known as akhavr | ||
mgz | rogpeppe: yeah, I broke eric the other day, will fix now and poke him again later to sort out | 08:07 |
* rogpeppe hopes eric can be fixed | 08:08 | |
=== akhavr1 is now known as akhavr | ||
=== akhavr1 is now known as akhavr | ||
=== akhavr1 is now known as akhavr | ||
dooferlad | voidspace: hangout time | 09:01 |
dooferlad | jam: hangout? | 09:04 |
voidspace | frobware: I've turned it into a PR so it can be reviewed, but I won't land it until we've confirmed it actually fixes the bug! | 09:36 |
voidspace | frobware: https://github.com/juju/juju/pull/3489 | 09:36 |
voidspace | frobware: bootstrapping against 1.9 now | 09:36 |
voidspace | bug updated as well | 09:38 |
frobware | voidspace, thanks - bbiab (rebooting)... | 09:38 |
voidspace | frobware: hmmm... two failed bootstraps | 10:01 |
voidspace | frobware: failing with 2015-10-13 10:00:33 WARNING juju.replicaset replicaset.go:98 Initiate: fetching replication status failed: cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG) | 10:01 |
voidspace | frobware: switched to 1.25 and trying to see if it fails in the same way | 10:02 |
frobware | voidspace, worked first time for me - using your branch | 10:02 |
voidspace | odd :-) | 10:02 |
voidspace | it could just be dumb luck | 10:02 |
frobware | voidspace, the times I see this I force a really clean build... | 10:02 |
voidspace | frobware: that's certainly not the failure I would expect | 10:03 |
voidspace | frobware: after I've tried vanilla 1.25 I'll rebuild and do a clean attempt | 10:03 |
voidspace | I would expect everything after the ifdown/ifup to fail | 10:03 |
voidspace | frobware: yeah, vanilla 1.25 fails much harder | 10:08 |
voidspace | frobware: so I'll call that a win ;-) | 10:08 |
voidspace | (fails earlier) | 10:08 |
frobware | voidspace, still going through the motions with multiple NICs | 10:08 |
voidspace | frobware: kk | 10:09 |
voidspace | in the meantime | 10:09 |
voidspace | dooferlad: TheMue: fancy a review? http://reviews.vapour.ws/r/2882/ | 10:10 |
voidspace | frobware: ah, a godeps made some changes, maybe that was it | 10:28 |
voidspace | trying yet again | 10:28 |
=== urulama is now known as urulama|afk | ||
frobware | voidspace, pretty sure that's why/when I see the replicaset issue. | 10:29 |
frobware | voidspace, posted a few comments and still doing some manual testing. | 10:29 |
voidspace | frobware: thanks | 10:31 |
voidspace | frobware: we can't create unit tests for machines with multiple nics I don't think | 10:31 |
voidspace | frobware: as the tests really just do text manipulation | 10:31 |
frobware | voidspace, I was thinking more of the case where we have multiple entries in the expected input/output tests. | 10:32 |
=== urulama|afk is now known as urulama | ||
voidspace | frobware: we use the primary interface as found from the "ip route list exact 0/0" command | 10:33 |
frobware | voidspace, so maybe I misread the test - let me take another look | 10:33 |
voidspace | frobware: nice improvement in those bash functions though | 10:35 |
voidspace | pushing now | 10:35 |
voidspace | frobware:can I drop that issue? | 10:49 |
frobware | voidspace, line 219 in environ_test.go - can we not simulate in there that there might be multiple NICs? | 10:52 |
voidspace | frobware: that's the script we generate - which is the same for multiple nics | 10:53 |
voidspace | frobware: we don't simulate the machine at all | 10:53 |
voidspace | that script has to *work* on machines with multiple nics - but is itself unchanged | 10:53 |
frobware | voidspace, that's just expected output though | 10:53 |
voidspace | that's the script itself | 10:53 |
voidspace | the output of generating the script | 10:53 |
frobware | voidspace, to me that's just test input/output, no? | 10:54 |
voidspace | frobware: well yes | 10:54 |
voidspace | frobware: but that input / output will be the same on a machine with multiple nics | 10:55 |
voidspace | we do not simulate the machine | 10:55 |
frobware | voidspace, so does it make sense to have a test that has multiple ethN entries? | 10:55 |
voidspace | we only generate the script and check the generated output matches what we expect | 10:55 |
voidspace | frobware: the script will never have multiple ethN entries | 10:55 |
voidspace | *running* the script on a machine with multiple nics will do something | 10:56 |
voidspace | but the unit tests never run that part of the code | 10:56 |
voidspace | frobware: see how that script doesn't mention ethN at all - but sets and uses $PRIMARY_IFACE | 10:57 |
voidspace | frobware: or are you talking about networkStaticInitial versus networkStaticFinal | 10:57 |
frobware | voidspace, sure, but the stuff I thought we were talking about was just text matching/replacement | 10:57 |
voidspace | frobware: and adding extra ethN entries in the canned /etc/network/interfaces ? | 10:58 |
voidspace | frobware: well it is | 10:58 |
frobware | voidspace, exactly | 10:58 |
voidspace | ah | 10:58 |
voidspace | frobware: I can add an extra entry and we can test it is left untouched | 10:58 |
voidspace | some value in that I guess | 10:58 |
frobware | voidspace, agreed | 10:58 |
voidspace | I'll add an extra test | 10:59 |
frobware | voidspace, I think there should be two: 1 with eth0, 1 with eth...ethN. | 10:59 |
voidspace | frobware: well I'll add one extra with an eth1 | 10:59 |
voidspace | frobware: if eth1 is untouched then adding ...ethN adds no extra value | 11:00 |
voidspace | we just want to test that "not the primary interface" is left intact | 11:00 |
voidspace | frobware: sorry for the misunderstanding :-) | 11:05 |
mup | Bug #1505617 opened: juju backup intermittent failure <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1505617> | 11:06 |
mup | Bug #1505617 changed: juju backup intermittent failure <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1505617> | 11:09 |
voidspace | frobware: additional test pushed | 11:10 |
mup | Bug #1505617 opened: juju backup intermittent failure <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1505617> | 11:12 |
frobware_ | voidspace, thanks | 11:15 |
frobware_ | voidspace, mgz: do we have an easy or existing mechanism to build a ppa for a proposed fix like this? | 11:19 |
voidspace | frobware_: I don't know, I don't think deploying a ppa is "simple" | 11:26 |
frobware_ | voidspace, heh, no. I've always used fpm when I wanted to do this. | 11:26 |
voidspace | frobware_: are you using trusty or vivid? | 11:27 |
voidspace | frobware_: on trusty I can bootstrap but then get the replset failure - reliably it seems | 11:27 |
frobware_ | voidspace, trusty | 11:27 |
voidspace | frobware_: I'm trying changing the images to see if that helps | 11:27 |
voidspace | probably a different mongo package | 11:27 |
voidspace | but if it works for you it shouldn't be that | 11:28 |
frobware_ | voidspace, to rebuild I use: alias rebuild-juju='[ -f $PWD/juju/api.go ] && { set -e; nukegopkg; make clean; godeps -u dependencies.tsv; make install; }' | 11:28 |
mgz | frobware_: people ask for ppas, but generally that's not actually useful for juju | 11:29 |
mgz | we're better off giving them some built binaries | 11:29 |
voidspace | mgz: frobware_ : in this case it's Mark Shuttleworth asking for a ppa... | 11:29 |
mgz | yeah, well that's always a fun conversation | 11:29 |
voidspace | oh no its not | 11:29 |
voidspace | <voidspace> frobware: additional test pushed | 11:29 |
voidspace | <mup> Bug # | 11:29 |
mgz | voidspace: you killed him | 11:30 |
voidspace | https://bugs.launchpad.net/juju-core/+bug/1494476 | 11:30 |
mup | Bug #1494476: MAAS provider with MAAS 1.9 - /etc/network/interfaces "auto eth0" gets removed and bridge is not setup <addressability> <lxc> <maas-provider> | 11:30 |
mup | <network> <juju-core:Triaged by mfoord> <juju-core 1.24:Triaged by mfoord> <juju-core 1.25:In Progress by mfoord> <https://launchpad.net/bugs/1494476> | 11:30 |
voidspace | it's andreserl asking | 11:30 |
voidspace | prebuild binaries should be enough | 11:30 |
mgz | yup. | 11:31 |
rogpeppe | mgz, anyone else: reviews much appreciated for this PR which fixes a critical issue: http://reviews.vapour.ws/r/2878/diff/# | 11:36 |
mgz | rogpeppe: I'll +1, looked at it yesterday | 11:38 |
rogpeppe | mgz: it's changed quite a bit since then | 11:38 |
rogpeppe | mgz: yesterday's didn't actually fix the problem | 11:38 |
rogpeppe | mgz: because we actually need to be able to log in | 11:39 |
rogpeppe | mgz: and the Login method i had fetched the environment config, which failed | 11:39 |
rogpeppe | mgz: so i've refactored things so agent login can be done without doing that | 11:39 |
mgz | ;_; | 11:39 |
rogpeppe | mgz: (which incidentally did simplify things a bit which was nice) | 11:40 |
mup | Bug #1505648 opened: meter-status worker spins if charm doesn't have meter-status-changed hook <logging> <manifold> <uniter> <juju-core:Triaged> <https://launchpad.net/bugs/1505648> | 11:48 |
voidspace | frobware: shall I land this branch | 12:05 |
frobware | voidspace, I was just about try / validate on 1.8 | 12:06 |
frobware | voidspace, give me 30 mins. OK? | 12:06 |
voidspace | frobware: sure | 12:19 |
frobware | voidspace, I ran into the replicaset issue too | 12:26 |
mattyw | mgz, ping? | 12:33 |
voidspace | frobware: 1.8 or 1.9? | 12:44 |
voidspace | or both :-( | 12:44 |
frobware | voidspace, 1.8. third time lucky?? now | 12:46 |
voidspace | frobware: did you work out how to get ssh access? | 12:46 |
frobware | voidspace, backdoor access? | 12:46 |
voidspace | yeah | 12:46 |
frobware | voidspace, nope :) | 12:46 |
voidspace | I'll try hacking cloud init config and ssh into the machine after a failed bootstrap | 12:46 |
voidspace | the machine is still running | 12:46 |
voidspace | frobware: I'm going to have lunch first | 12:46 |
frobware | voidspace, me too. though the patch seems fine for the combos I have tried on 1.8 and 1.9 | 12:47 |
voidspace | frobware: if it works sometimes that implies a timing issue | 12:47 |
voidspace | yeah, odd :-/ | 12:47 |
frobware | voidspace, and I tried 1.9 way more | 12:47 |
voidspace | annoying | 12:47 |
perrito666 | belated good morning all | 13:00 |
mgz | mattyw: hey, what's up? | 13:26 |
mattyw | mgz, hey hey - sorry you can ignore me | 13:27 |
mattyw | mgz, I found some docs I could read instead of pestering others :) | 13:27 |
mgz | :) | 13:27 |
mup | Bug #1505617 changed: juju backup intermittent failure <backup-restore> <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1505617> | 14:00 |
mgz | bogdanteleaga: wotcha, you around? need to bother you about centos testing | 14:30 |
mgz | ericsnow: also poké, when you have a mo, to talk about reviewboard github persm | 14:32 |
ericsnow | mgz: k (OTP) | 14:32 |
rogpeppe | mgz: did you forget to publish your review of http://reviews.vapour.ws/r/2878/ ? | 14:41 |
mgz | rogpeppe: yeah, need to finish that | 14:47 |
rogpeppe | mgz: thanks | 14:47 |
mgz | rogpeppe: okay, the thing I am hung up on, and why I didn't finish looking through the code yesterday, | 14:50 |
mgz | is one we've started the server, what's to stop something connecting before all the upgrades have actually happened | 14:51 |
mgz | the ordering around this hurts my head | 14:51 |
rogpeppe | mgz: the machine agent has logic in it to stop that | 14:54 |
rogpeppe | mgz: and i agree, it's a pain to reason about and should really be fixed at a more fundamental level | 14:54 |
rogpeppe | mgz: but this at least works around the issue for now and is no worse than what we had before | 14:55 |
rogpeppe | mgz: i think that probably mongo schema upgrades should be treated entirely separately from the other upgrades | 14:55 |
rogpeppe | mgz: but that's too big a change for me to do right now (and it's not really my responsibility to fix old juju tech debt tbh) | 14:56 |
mgz | rogpeppe: I agree this is better, will plus one and give in to the fact I don't comprehend all of cmd/jujud/agent/ | 14:56 |
rogpeppe | mgz: y'know, looking at the code, i'm no longer convinced that it does | 15:00 |
mgz | ehehe ;_; | 15:01 |
rogpeppe | mgz: but again, it's no different to how it was before | 15:03 |
mgz | rogpeppe: you have reviews. | 15:04 |
rogpeppe | mgz: ta! | 15:04 |
voidspace | frobware: this is the /etc/network/interfaces I have | 15:18 |
voidspace | juju-dev | 15:18 |
voidspace | * gberginc has quit (Quit: -sigh-) | 15:18 |
voidspace | frobware: http://pastebin.ubuntu.com/12773634/ | 15:18 |
voidspace | a bit weird | 15:18 |
voidspace | ah | 15:18 |
voidspace | auto eth0:1 | 15:18 |
voidspace | has been replaced with "auto juju-br0:1" | 15:19 |
voidspace | funnily enough it occured to me that the sed we were using would clobber interface names where the primary interface was *part* of another interface | 15:19 |
voidspace | dammit | 15:19 |
voidspace | ok, easy enough to fix and test I think | 15:19 |
mattyw | mgz, here's my yaml migration pr http://reviews.vapour.ws/r/2883/ | 15:20 |
voidspace | dooferlad: ping | 15:26 |
mgz | mattyw: thanks! | 15:27 |
mgz | mattyw: anything particularly fun? | 15:27 |
mattyw | mgz, there was one place where yaml setters and getters were changed and I think that reduced line count | 15:28 |
mattyw | mgz, and also there was some validation that just wan't needed anymore | 15:28 |
mattyw | mgz, https://github.com/juju/juju/pull/3490/files#diff-992668ccf77c55eabded974107a15a3bL94 | 15:29 |
frobware | voidspace, how did you get it into that state? | 15:30 |
mgz | mattyw: is it worth wrapping errors from marshal funcs, or will we get enough context anyway? | 15:30 |
voidspace | frobware: that's after a fresh bootstrap | 15:30 |
voidspace | frobware: for some reason it has an "auto eth0:1" in it initially | 15:30 |
frobware | voidspace, I did not run into that case | 15:30 |
voidspace | frobware: were you able to ssh in? | 15:31 |
frobware | voidspace, this through adding additional NICs via MAAS? | 15:31 |
voidspace | frobware: that's ssh'ing into the failed bootstrap node | 15:31 |
frobware | voidspace, ah. without your change? | 15:31 |
voidspace | frobware: the sed code (pre-existing I might add) badly mangles "ssh eth0:1" into "auto juju-br0:1" | 15:31 |
voidspace | frobware: no, that's with my change | 15:31 |
mattyw | mgz, I think we get enough context - but opinions may vary | 15:32 |
voidspace | frobware: so I can fix that problem and see if it fixes the replicaset issue | 15:32 |
frobware | voidspace, I never saw that generated with multiple NICs. | 15:32 |
voidspace | just bootstrapping now to see if I've fixed it | 15:32 |
mattyw | mgz, for example for long sequences or maps you don't get much feedback | 15:32 |
voidspace | frobware: even when bootstrap failed? | 15:32 |
mattyw | mgz, but in the cases I've changed you're likely to know what was input anyway | 15:32 |
frobware | voidspace, the only time I saw bootstrap fail (on 1.9) was when I was not running your branch | 15:32 |
frobware | voidspace, btw - I'm currently running 1.25 in a bootstrap/destroy loop and have not seen the replicaset failure. | 15:33 |
voidspace | frobware: with my fix in place I still have an eth0:1, but it isn't mangled by sed | 15:34 |
voidspace | so maybe it will work this time | 15:34 |
voidspace | bootstrap still in progress | 15:34 |
frobware | voidspace, it's not clear to me how you got :1 added | 15:34 |
voidspace | frobware: that's the *initial* /etc/network/interfaces that cloud init modifies | 15:35 |
voidspace | so it comes from maas | 15:35 |
frobware | voidspace, have not seen that. | 15:35 |
voidspace | it has a different address! | 15:35 |
voidspace | the machine has two addresses | 15:35 |
frobware | voidspace, two addresses, 1 NIC? | 15:35 |
voidspace | yep | 15:35 |
frobware | voidspace, aha. Thought you were getting this on 2 NICs- confused. | 15:36 |
voidspace | I have no idea why it is there | 15:36 |
voidspace | but it is, and juju is no longer mangling it | 15:36 |
voidspace | frobware: so the fix is good I think | 15:37 |
voidspace | frobware: I'll push shortly with an extra test | 15:37 |
voidspace | well, if the bootstrap works that is... | 15:37 |
voidspace | nope, same problem | 15:37 |
voidspace | so I think this additional interface in /etc/network/interfaces must be the problem | 15:37 |
voidspace | I wonder if bootstrapping to a different node, not screwed up, would help | 15:38 |
voidspace | I've acquired that node to force maas to pick a different one for bootstrap | 15:38 |
voidspace | trying again | 15:38 |
frobware | voidspace, and the new node has an alias too? | 15:39 |
voidspace | frobware: don't know - will see shortly | 15:39 |
frobware | voidspace, I just added one to my node... previously I was only concentrating on two NICs. | 15:39 |
voidspace | frobware: as far as I can *see* the alias (if that's what it is) isn't defined in virt-manager | 15:39 |
voidspace | no idea where it came from | 15:40 |
frobware | voidspace, I added the alias in the MAAS screen | 15:40 |
frobware | voidspace, so I see eth0 and eth0:1 each with their own addrs | 15:40 |
voidspace | ah, ok - looking at the node in maas | 15:40 |
voidspace | ah yes, it's there | 15:40 |
voidspace | frobware: the other nodes don't have aliases | 15:41 |
voidspace | so that's the problem | 15:41 |
frobware | voidspace, but it is a legitimate combo. | 15:41 |
voidspace | frobware: well, it is | 15:41 |
voidspace | frobware: but it's an existing problem | 15:41 |
voidspace | let's fix the reported bug | 15:41 |
voidspace | and file a new one for the alias | 15:41 |
voidspace | as the current bug is urgent | 15:41 |
frobware | voidspace, fair enough | 15:42 |
frobware | voidspace, but I think we would have to get the new bug fix into 1.25 as well | 15:42 |
voidspace | that would depend on priority of that bug :-) | 15:42 |
voidspace | I also don't immediately know the right fix | 15:43 |
voidspace | I think we would probably need to add bridge_ports to all aliases too | 15:43 |
voidspace | frobware: I'll leave the fix to not *mangle* aliases in | 15:43 |
voidspace | as it's more correct | 15:43 |
voidspace | so I'll write the extra test | 15:43 |
voidspace | but that scenario still doesn't work | 15:44 |
voidspace | I assume because the alias isn't routable and mongo is picking that address | 15:44 |
frobware | voidspace, agreed to not mangling aliases | 15:44 |
voidspace | cool | 15:44 |
voidspace | frobware: bootstrap just worked | 15:48 |
voidspace | so that was it | 15:48 |
frobware | voidspace, if it's obvious I'm inclined to make sure it works with aliases too | 15:49 |
voidspace | frobware: it's not obvious to me | 15:54 |
voidspace | frobware: but it's *probably* not hard | 15:54 |
voidspace | let's land this and I can work on it alongside | 15:54 |
frobware | voidspace, ack | 15:54 |
frobware | voidspace, whilst testing your bits I may have made some progress with addressable containers and macvlan... | 15:55 |
voidspace | frobware: latest version pushed | 15:55 |
voidspace | frobware: cool | 15:55 |
voidspace | frobware: if you fancy a quick look over and giving me a ShipIt I'll land it | 15:55 |
frobware | voidspace, looking and trying now... | 15:56 |
voidspace | and then I'll do back/forward ports | 15:56 |
voidspace | although dimitern said he has a simpler fix for 1.24 | 15:56 |
voidspace | not sure what that is | 15:56 |
frobware | voidspace, heh - the node I'm using is entitled 'elegant-belief'. :) | 15:57 |
frobware | voidspace, I think the simper fix is just 2 invocations of sed. one to replace, one to insert the bridge bits. | 15:57 |
voidspace | ah, ok | 15:58 |
voidspace | maas node names are lovely | 15:59 |
voidspace | I'm on imaginative-hose | 15:59 |
mattyw | I wonder which meaning of hose they had in mind | 15:59 |
voidspace | heh | 16:00 |
voidspace | all of them | 16:00 |
frobware | voidspace, I wonder whether as debug we should $(cat /e/n/i) before and after our mods. At least the former may show up before we nuke any access... | 16:07 |
voidspace | frobware: to the client? | 16:08 |
frobware | voidspace, wherever debug goes | 16:09 |
voidspace | frobware: I don't think there is any debug output from cloud init | 16:09 |
voidspace | frobware: we could save a copy before mangling it | 16:09 |
frobware | voidspace, but this is juju doing this bit | 16:09 |
voidspace | frobware: this is cloud init | 16:10 |
voidspace | frobware: this is a bash script we send to the machine using cloud init | 16:10 |
frobware | voidspace, oh. I though juju did this in place | 16:10 |
voidspace | no, that's why we have to use bash | 16:10 |
voidspace | it's not the juju executable doing this | 16:10 |
voidspace | it's bash code executed as part of machine setup | 16:11 |
frobware | voidspace, so it could still be logged. | 16:11 |
voidspace | frobware: using syslog? | 16:12 |
voidspace | it's before there's a juju log file | 16:12 |
frobware | voidspace, cloud-init can log stuff too | 16:12 |
voidspace | ok | 16:13 |
frobware | voidspace, just to be clear - your latest change is not alias aware, correct? | 16:13 |
voidspace | frobware: it has changes to not mangle aliases | 16:13 |
voidspace | but it doesn't work with aliases | 16:13 |
voidspace | so basically correct, yes | 16:13 |
frobware | voidspace, so no bootstrap possible with aliases (eth0:1)? | 16:14 |
voidspace | frobware: that's correct, but it's also correct with trunk | 16:14 |
voidspace | the new code is marginally better | 16:14 |
voidspace | as trunk code will mangle aliases | 16:14 |
frobware | voidspace, because it does bootstrap OK for me with aliases | 16:15 |
voidspace | frobware: no replicaset issue? | 16:15 |
frobware | voidspace, nope. here with aliases: http://pastebin.ubuntu.com/12773981/ | 16:15 |
voidspace | frobware: deleting the alias solved the replicaset problem for me | 16:15 |
voidspace | frobware: using my branch? | 16:16 |
voidspace | frobware: right, I guet that output - but bootstrap fails | 16:16 |
voidspace | it maybe intermittent | 16:16 |
voidspace | it probably depends which address of the two that mongo reports first | 16:16 |
frobware | voidspace, 7a13a40365df2aa5f13572955783a8ac60fb0dd6 Don't mangle aliases | 16:16 |
voidspace | frobware: cool | 16:17 |
voidspace | frobware: I'll add an alias and try again | 16:17 |
voidspace | frobware: in the meantime, care to give me a ShipIt? | 16:17 |
voidspace | right, bootstrap in progress | 16:19 |
frobware | voidspace, I added one more alias and it no longer bootstraps for me. | 16:24 |
voidspace | heh | 16:24 |
voidspace | frobware: really we would want mongo to use the primary interface not the alias | 16:26 |
voidspace | so I wonder if that's the real problem here | 16:26 |
frobware | voidspace, so the script output ends up in /var/lib/juju/nonce.txt - so we could add the cat before/after to see what we did... | 16:27 |
frobware | voidspace, correction in /var/log/cloud-init-output.log | 16:27 |
voidspace | ah, right | 16:27 |
voidspace | we don't need after, as that's what's in /e/n/i anyway | 16:27 |
voidspace | just before | 16:27 |
voidspace | why the $(cat ...) ? | 16:28 |
voidspace | why not just "cat ..." | 16:28 |
frobware | voidspace, the $(...) was just be delimiting in the written prose... | 16:29 |
voidspace | ah :-) | 16:29 |
frobware | voidspace, the after is a sanity check if the cloud-init is logged to a console and e/n/i is borked. there's then a chance we could see why. | 16:30 |
voidspace | ok... | 16:31 |
frobware | voidspace, so your most recent change does handle the alias -- or so it seems to me. | 16:34 |
voidspace | frobware: ok, that's good | 16:35 |
voidspace | frobware: we can topic it in tomorrow's standup | 16:35 |
frobware | voidspace, added a shipit - do you plan to post any binaries? | 16:38 |
voidspace | frobware: I can create some I guess | 16:39 |
voidspace | wonder where they should go | 16:39 |
frobware | voidspace, http://people.canonical.com/~voidspace | 16:40 |
voidspace | frobware: ah | 16:41 |
voidspace | never used that... | 16:41 |
voidspace | I'll look into it | 16:41 |
voidspace | heh, 404 | 16:42 |
frobware | voidspace, nor me. I just saw dimiter publish some stuff there the other day... not sure I can login atm. | 16:42 |
frobware | voidspace, I think you first need to create public_html | 16:42 |
voidspace | right | 16:42 |
voidspace | I'll look into it in a bit - some exercise first | 16:42 |
voidspace | I've set my branch to land on 1.25 | 16:42 |
mgz | voidspace: you can (with vpn or chinstrap) scp to lillypilly.canonical.com:~/public_html | 16:42 |
mgz | though it likes scri | 16:43 |
voidspace | mgz: thanks | 16:43 |
mgz | ..screwing up file persm so you have to ssh in to make apache like it anywa | 16:43 |
voidspace | heh, right | 16:43 |
natefinch | ericsnow: anything I can do to help? | 16:46 |
ericsnow | natefinch: I don't think so | 16:47 |
ericsnow | natefinch: you could look through the TODOs in that PR | 16:47 |
natefinch | ericsnow: the LXD PR? | 16:47 |
frobware | voidspace, you still there? | 16:48 |
frobware | voidspace, this worked for me: ssh -i ~/.ssh/id_launchpad_rsa people.canonical.com | 16:48 |
ericsnow | natefinch: yeah, that would help, but I was thinking of the list-payloads one (which probably doesn't actually have many TODOs) | 16:48 |
voidspace | frobware: cool, thanks | 16:49 |
frobware | voidspace, you'll need to be on the VPN | 16:49 |
natefinch | ericsnow: sure, I can look at that one. Probably have a better base of knowledge for it anyway. | 16:49 |
voidspace | frobware: bootstrap with an alias just worked for me too | 16:50 |
frobware | voidspace, it seems a nice by product of the \s* sed/grep match | 16:50 |
voidspace | yeah | 16:51 |
voidspace | not mangling things is generally good... | 16:51 |
frobware | s/nice/natural <shrug> | 16:51 |
voidspace | :) | 16:51 |
frobware | voidspace, we're just waiting for that to merge in 1.25, correct? | 16:52 |
voidspace | yep | 16:52 |
voidspace | then porting to master | 16:52 |
frobware | voidspace, if so could you update the bug report so at least everybody knows current status. thx. | 16:52 |
voidspace | and maybe 1.24 depending on if dimiter prefers his fix | 16:52 |
voidspace | yep | 16:52 |
voidspace | frobware: updated, really going now | 16:54 |
frobware | voidspace, me too. thanks! | 16:54 |
natefinch | ericsnow: I don't really see any super important todos that need to get done for that code. Mostly just nice-to-haves and/or open questions. | 16:54 |
ericsnow | natefinch: k | 16:55 |
natefinch | (that code = payloads list) | 16:55 |
ericsnow | natefinch: perhaps catalog what tests are missing? | 16:55 |
natefinch | ericsnow: good idea | 16:55 |
natefinch | ericsnow: I started doing the list as another review of the code, but would it be more useful in textual form? So we could put it in a card and anyone could work on it/ | 17:04 |
ericsnow | natefinch: sgtm | 17:12 |
katco | ericsnow: wwitzel3: time to start again | 17:37 |
=== coreycb` is now known as coreycb | ||
ericsnow | wwitzel3: FYI, my list-payloads patch works now | 20:35 |
thumper | dooferlad: ping | 20:47 |
cherylj | Hey davechen1y, are you actively working on bug 1465317 | 21:14 |
mup | Bug #1465317: Wily osx win: panic: osVersion reported an error: Could not determine series <osx> <packaging> <wily> <windows> <juju-core:In Progress by dave-cheney> <juju-core 1.24:Triaged> <juju-core 1.25:Triaged> <juju-release-tools:Fix Released by sinzui> <https://launchpad.net/bugs/1465317> | 21:15 |
thumper | cherylj: what's the concern with http://reviews.vapour.ws/r/2868/ | 21:22 |
cherylj | thumper: look at http://reviews.vapour.ws/r/2854/ | 21:23 |
thumper | looking there now actually | 21:23 |
* thumper thinks | 21:23 | |
wwitzel3 | ericsnow: awesome, will check it out now | 21:24 |
mattyw | thumper, while we happen to be in the same place (irc) at the same time (now) have you seen rog' email on juju-dev about the user names local domain stuff, and do you have any problem with it? | 21:50 |
thumper | no, not seen it yet | 21:50 |
thumper | so no comment | 21:50 |
mattyw | thumper, ok, I figured that might be the case, just wanted to check | 21:52 |
mattyw | thumper, it's no particularly urgent | 21:52 |
* thumper headdesks | 22:11 | |
thumper | two hours at work and it has started already | 22:12 |
thumper | FFS | 22:12 |
mgz | no, no, the poor desk | 22:12 |
mgz | mattyw: reviewed your branch earlier btw | 22:13 |
mattyw | mgz, I saw, thanks very much | 22:13 |
mattyw | mgz, I'm saving the work until tomrrow | 22:13 |
mattyw | mgz, something to look forward to | 22:13 |
mgz | :D | 22:14 |
thumper | cherylj: you were right to be concerned about the flslock changes | 22:14 |
* thumper brings up a juju/utils branch | 22:14 | |
mgz | thumper: my argument was we just want to do what bzr used to, which is `kill -0 pid` | 22:15 |
mgz | which approximately works everywhere | 22:15 |
thumper | what is that? | 22:15 |
mgz | just check if the pid in the lock is alive | 22:16 |
mgz | no fancy stuff | 22:16 |
thumper | kill works on windows? | 22:17 |
thumper | I do agree, no fancy stuff | 22:17 |
mgz | there's a very similar equivalent with TerminateProcess | 22:17 |
thumper | surely there is a way to get Go to tell us about a pid | 22:17 |
thumper | implicit breaking of a lock is bad IMO | 22:18 |
thumper | there are better ways | 22:18 |
mgz | I agree just using a better lock primative would be better regardless | 22:19 |
thumper | http://stackoverflow.com/questions/15204162/check-if-a-process-exists-in-go-way | 22:22 |
thumper | mgz: this does what you said the Go way | 22:22 |
mgz | thumper: looks like we'd actually want x/sys/unix Kill | 22:23 |
thumper | no, because windows | 22:23 |
mgz | I have doubts process.Signal does the right thing on windows | 22:24 |
thumper | I'll write a test and check :-) | 22:24 |
* thumper goes to walk the dog to clear thinking | 22:46 | |
wallyworld | perrito666: anastasiamac: running a bit late | 23:15 |
anastasiamac | wallyworld: k. ping when ready :D | 23:15 |
perrito666 | wallyworld: ack | 23:15 |
davechen1y | is anyone on call reviewer today ? | 23:21 |
perrito666 | davechen1y: I still am | 23:21 |
perrito666 | at least in my tz | 23:21 |
* perrito666 shifted his day a bit to the right | 23:22 | |
davechen1y | http://reviews.vapour.ws/r/2881/ | 23:22 |
davechen1y | http://reviews.vapour.ws/r/2880/ | 23:22 |
davechen1y | if you have time please | 23:22 |
perrito666 | davechen1y: syre | 23:22 |
perrito666 | sure | 23:22 |
wallyworld | anastasiamac: here now | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!