[01:07] <mup> Bug #1505460 opened: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460>
[01:10] <mup> Bug #1505460 changed: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460>
[01:13] <mup> Bug #1505460 opened: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460>
[01:16] <mup> Bug #1505460 changed: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460>
[01:19] <mup> Bug #1505460 opened: Image consistency with containers can be broken <juju-core:New> <https://launchpad.net/bugs/1505460>
[03:42] <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
[05:23] <mup> Bug #1505504 opened: error when destroying current environment in a multi-environment scenario <juju-core:New> <https://launchpad.net/bugs/1505504>
[05:32] <mup> Bug #1505504 changed: error when destroying current environment in a multi-environment scenario <juju-core:New> <https://launchpad.net/bugs/1505504>
[05:47] <mup> Bug #1505504 opened: error when destroying current environment in a multi-environment scenario <juju-core:New> <https://launchpad.net/bugs/1505504>
[06:57] <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)
[08:07] <mgz> rogpeppe: yeah, I broke eric the other day, will fix now and poke him again later to sort out
[08:08]  * rogpeppe hopes eric can be fixed
[09:01] <dooferlad> voidspace: hangout time
[09:04] <dooferlad> jam: hangout?
[09:36] <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:38] <voidspace> bug updated as well
[09:38] <frobware> voidspace, thanks - bbiab (rebooting)...
[10:01] <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:02] <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:03] <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:08] <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:09] <voidspace> frobware: kk
[10:09] <voidspace> in the meantime
[10:10] <voidspace> dooferlad: TheMue: fancy a review? http://reviews.vapour.ws/r/2882/
[10:28] <voidspace> frobware: ah, a godeps made some changes, maybe that was it
[10:28] <voidspace> trying yet again
[10:29] <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:31] <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:32] <frobware> voidspace, I was thinking more of the case where we have multiple entries in the expected input/output tests.
[10:33] <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:35] <voidspace> frobware: nice improvement in those bash functions though
[10:35] <voidspace> pushing now
[10:49] <voidspace> frobware:can I drop that issue?
[10:52] <frobware> voidspace, line 219 in environ_test.go - can we not simulate in there that there might be multiple NICs?
[10:53] <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:54] <frobware> voidspace, to me that's just test input/output, no?
[10:54] <voidspace> frobware: well yes
[10:55] <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:56] <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:57] <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:58] <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:59] <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
[11:00] <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:05] <voidspace> frobware: sorry for the misunderstanding :-)
[11:06] <mup> Bug #1505617 opened: juju backup intermittent failure <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1505617>
[11:09] <mup> Bug #1505617 changed: juju backup intermittent failure <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1505617>
[11:10] <voidspace> frobware: additional test pushed
[11:12] <mup> Bug #1505617 opened: juju backup intermittent failure <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1505617>
[11:15] <frobware_> voidspace, thanks
[11:19] <frobware_> voidspace, mgz: do we have an easy or existing mechanism to build a ppa for a proposed fix like this?
[11:26] <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:27] <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:28] <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:29] <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
 frobware: additional test pushed
 Bug #
[11:30] <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>
 <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:31] <mgz> yup.
[11:36] <rogpeppe> mgz, anyone else: reviews much appreciated for this PR which fixes a critical issue: http://reviews.vapour.ws/r/2878/diff/#
[11:38] <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:39] <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:40] <rogpeppe> mgz: (which incidentally did simplify things a bit which was nice)
[11:48] <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>
[12:05] <voidspace> frobware: shall I land this branch
[12:06] <frobware> voidspace, I was just about try / validate on 1.8
[12:06] <frobware> voidspace, give me 30 mins. OK?
[12:19] <voidspace> frobware: sure
[12:26] <frobware> voidspace, I ran into the replicaset issue too
[12:33] <mattyw> mgz, ping?
[12:44] <voidspace> frobware: 1.8 or 1.9?
[12:44] <voidspace> or both :-(
[12:46] <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:47] <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
[13:00] <perrito666> belated good morning all
[13:26] <mgz> mattyw: hey, what's up?
[13:27] <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> :)
[14:00] <mup> Bug #1505617 changed: juju backup intermittent failure <backup-restore> <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1505617>
[14:30] <mgz> bogdanteleaga: wotcha, you around? need to bother you about centos testing
[14:32] <mgz> ericsnow: also poké, when you have a mo, to talk about reviewboard github persm
[14:32] <ericsnow> mgz: k (OTP)
[14:41] <rogpeppe> mgz: did you forget to publish your review of http://reviews.vapour.ws/r/2878/ ?
[14:47] <mgz> rogpeppe: yeah, need to finish that
[14:47] <rogpeppe> mgz: thanks
[14:50] <mgz> rogpeppe: okay, the thing I am hung up on, and why I didn't finish looking through the code yesterday,
[14:51] <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:54] <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:55] <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:56] <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/
[15:00] <rogpeppe> mgz: y'know, looking at the code, i'm no longer convinced that it does
[15:01] <mgz> ehehe ;_;
[15:03] <rogpeppe> mgz: but again, it's no different to how it was before
[15:04] <mgz> rogpeppe: you have reviews.
[15:04] <rogpeppe> mgz: ta!
[15:18] <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:19] <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:20] <mattyw> mgz, here's my yaml migration pr http://reviews.vapour.ws/r/2883/
[15:26] <voidspace> dooferlad: ping
[15:27] <mgz> mattyw: thanks!
[15:27] <mgz> mattyw: anything particularly fun?
[15:28] <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:29] <mattyw> mgz, https://github.com/juju/juju/pull/3490/files#diff-992668ccf77c55eabded974107a15a3bL94
[15:30] <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:31] <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:32] <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:33] <frobware> voidspace, btw - I'm currently running 1.25 in a bootstrap/destroy loop and have not seen the replicaset failure.
[15:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:43] <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:44] <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:48] <voidspace> frobware: bootstrap just worked
[15:48] <voidspace> so that was it
[15:49] <frobware> voidspace, if it's obvious I'm inclined to make sure it works with aliases too
[15:54] <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:55] <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:56] <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:57] <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:58] <voidspace> ah, ok
[15:59] <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
[16:00] <voidspace> heh
[16:00] <voidspace> all of them
[16:07] <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:08] <voidspace> frobware: to the client?
[16:09] <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:10] <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:11] <voidspace> it's bash code executed as part of machine setup
[16:11] <frobware> voidspace, so it could still be logged.
[16:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:19] <voidspace> right, bootstrap in progress
[16:24] <frobware> voidspace, I added one more alias and it no longer bootstraps for me.
[16:24] <voidspace> heh
[16:26] <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:27] <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:28] <voidspace> why the $(cat ...) ?
[16:28] <voidspace> why not just "cat ..."
[16:29] <frobware> voidspace, the $(...) was just be delimiting in the written prose...
[16:29] <voidspace> ah :-)
[16:30] <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:31] <voidspace> ok...
[16:34] <frobware> voidspace, so your most recent change does handle the alias -- or so it seems to me.
[16:35] <voidspace> frobware: ok, that's good
[16:35] <voidspace> frobware: we can topic it in tomorrow's standup
[16:38] <frobware> voidspace, added a shipit - do you plan to post any binaries?
[16:39] <voidspace> frobware: I can create some I guess
[16:39] <voidspace> wonder where they should go
[16:40] <frobware> voidspace, http://people.canonical.com/~voidspace
[16:41] <voidspace> frobware: ah
[16:41] <voidspace> never used that...
[16:41] <voidspace> I'll look into it
[16:42] <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:43] <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:46] <natefinch> ericsnow: anything I can do to help?
[16:47] <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:48] <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:49] <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:50] <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:51] <voidspace> yeah
[16:51] <voidspace> not mangling things is generally good...
[16:51] <frobware> s/nice/natural <shrug>
[16:51] <voidspace> :)
[16:52] <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:54] <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:55] <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
[17:04] <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:12] <ericsnow> natefinch: sgtm
[17:37] <katco> ericsnow: wwitzel3: time to start again
[20:35] <ericsnow> wwitzel3: FYI, my list-payloads patch works now
[20:47] <thumper> dooferlad: ping
[21:14] <cherylj> Hey davechen1y, are you actively working on bug 1465317
[21:15] <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:22] <thumper> cherylj: what's the concern with http://reviews.vapour.ws/r/2868/
[21:23] <cherylj> thumper: look at http://reviews.vapour.ws/r/2854/
[21:23] <thumper> looking there now actually
[21:23]  * thumper thinks
[21:24] <wwitzel3> ericsnow: awesome, will check it out now
[21:50] <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:52] <mattyw> thumper, ok, I figured that might be the case, just wanted to check
[21:52] <mattyw> thumper, it's no particularly urgent
[22:11]  * thumper headdesks
[22:12] <thumper> two hours at work and it has started already
[22:12] <thumper> FFS
[22:12] <mgz> no, no, the poor desk
[22:13] <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:14] <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:15] <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:16] <mgz> just check if the pid in the lock is alive
[22:16] <mgz> no fancy stuff
[22:17] <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:18] <thumper> implicit breaking of a lock is bad IMO
[22:18] <thumper> there are better ways
[22:19] <mgz> I agree just using a better lock primative would be better regardless
[22:22] <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:23] <mgz> thumper: looks like we'd actually want x/sys/unix Kill
[22:23] <thumper> no, because windows
[22:24] <mgz> I have doubts process.Signal does the right thing on windows
[22:24] <thumper> I'll write a test and check :-)
[22:46]  * thumper goes to walk the dog to clear thinking
[23:15] <wallyworld> perrito666: anastasiamac: running a bit late
[23:15] <anastasiamac> wallyworld: k. ping when ready :D
[23:15] <perrito666> wallyworld: ack
[23:21] <davechen1y> is anyone on call reviewer today ?
[23:21] <perrito666> davechen1y: I still am
[23:21] <perrito666> at least in my tz
[23:22]  * 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:26] <wallyworld> anastasiamac: here now