[01:24] axw: http://paste.ubuntu.com/6957563/ [01:24] can you assist with a local provider issue [01:25] buh [01:25] umm [01:25] what version of juju is that? [01:25] oh, 1.17.3.1 ... [01:26] this looks a lot like a bug that was fixed already [01:26] is trunk up to date? [01:39] that is a pull as of 60 minutes ago [01:42] axw: is it that juju doenst' know ppc64 is a valid arch ? [01:46] davecheney: so there's two problems [01:46] 1) can't bootstrap [01:46] 2) destroy is finding the wrong binary [01:46] local provider destroy now calls juju again with sudo under the covers [01:46] seems to be finding an old binary that doesn't have the -y flag [01:47] davecheney: as for why it can't find matching tools... I have no idea. could be because of the valid arches, as you say [01:55] davecheney: can you try with --debug please? [01:55] davecheney: you may need to update environs/tools/tools.go, makeToolsConstraint [01:55] toolsConstraint.Arches = ... [01:59] davecheney: and I've filed https://bugs.launchpad.net/juju-core/+bug/1281863 to fix the destroy issue [01:59] <_mup_> Bug #1281863: local: Destroy assumes it is called from "juju destroy-environment" [03:13] axw: thanks [03:14] there is still some confusoin about the 'official' name for ppc64 [03:14] go calls it ppc64, but uname -m and others append a suffix [03:16] axw: 2014-02-19 03:16:11 DEBUG juju.environs.simplestreams simplestreams.go:471 index file has no data for product name(s) ["com.ubuntu.juju:12.10:amd64" "com.ubuntu.j│······· [03:16] uju:12.10:i386" "com.ubuntu.juju:12.10:arm" "com.ubuntu.juju:12.04:amd64" "com.ubuntu.juju:12.04:i386" "com.ubuntu.juju:12.04:arm" "com.ubuntu.juju:13.10:amd64" "│······· [03:16] com.ubuntu.juju:13.10:i386" "com.ubuntu.juju:13.10:arm" "com.ubuntu.juju:14.04:amd64" "com.ubuntu.juju:14.04:i386" "com.ubuntu.juju:14.04:arm" "com.ubuntu.juju:13│······· [03:16] .04:amd64" "com.ubuntu.juju:13.04:i386" "com.ubuntu.juju:13.04:arm"] [03:16] basicallyt not ppc64 arch [03:17] davecheney: even with the change? [03:17] to tools.go [03:17] sorry, missed that bit [03:17] will bodge [03:21] axw: it worked! [03:21] swoit :) [03:25] patch incoming [03:41] axw: sonofabitch [03:41] but can't I get the environ/tools tests to recognose trusty as a series [03:46] umm [03:47] davecheney: does the csv file have the right thing in it? [03:47] i thought this was all table driven from ../envions/testing/tools.go [03:48] oh tests [03:49] yeah, just trying to add a test that shows we can find ppc tools [03:49] davecheney: not really sure sorry. I guess one of the tests is using version.Current, but uploading fake tools for only older series [04:19] i'll keep hacking on it [04:19] i can at least get to the next problem [08:31] davecheney, axw: are you working on https://bugs.launchpad.net/juju-core/+bug/1274755 ? [08:31] <_mup_> Bug #1274755: simplestreams test metadata only lists tools for arm and amd64 [08:36] mwhudson: I'm not, but davecheney has been working in that vicinity... [08:36] ok [09:05] rogpeppe, hey [09:05] dimitern: hiya [09:05] hi, what 's the state of juju add-machine kvm ? [09:05] rogpeppe, is there a particular reason debug log is streamed through a websocket rather than https? [09:06] dimitern: because i consulted with the GUI folks and that's what they suggested [09:06] dimitern: websockets are designed for long-lived connections [09:06] chris38, it's done afaik [09:06] dimitern: which https connections aren't really [09:07] rogpeppe, they could be, but meh [09:07] rogpeppe, ok, and the log-location passing through the agent conf should be in StateMachineConfig perhaps? [09:07] dimitern: ah, there is a very good reason it's a websocket actually [09:07] dimitern: 'cos it's a bidirectional connection [09:08] rogpeppe, ah, that looks like a better reason :) [09:08] dimitern: yeah, StateMachineConfig looks like a good place for it [09:09] I built juj from source the command is executed, but the server stay in pending mode, do I have to install some libvirt stuffs on the maas vm ? === axw_ is now known as axw [09:17] dimitern, any tip / doc on how to make juju add-machine kvm work ? [09:19] chris38, I think in order to be able to spin up kvm machines certain dependencies have to be met, libvirt included, let me browse through the commit log for clues [09:20] axw_, does add-machine support adding kvm containers? [09:21] axw_, it seems it should, but I can't see updated help docs or tests about it [09:21] dimitern: I'm not sure sorry [09:22] dimitern: thumper would be the one to ping about it. It was supposed to work, and the extra libs are supposed to be installed when a unit sees it needs a KVM target === jam1 is now known as jam [09:24] jam, chris38, so if it doesn't work I think it deserves a bug then [09:25] I'll check more with installing manually libvirt, and submit a bug [09:43] what the magic command to update from source and rebuild juju ? after initial go install -v launchpad.net/juju-core/... [10:12] chris38, I'm using this handy bash script: http://paste.ubuntu.com/6959163/ - replace /home/dimitern/work/juju-core with the path to your source checkout [10:24] dimitern, thx ;-) [10:48] dimitern, jam, fwereade: our standup time seems to have moved back an hour - is that correct? [10:48] rogpeppe: it is now, but that is the same time its been [10:48] did you have a TZ change? [10:50] jam: no [10:50] jam: it says an hour later than usual on the calendar [11:49] rogpeppe, when I come to submit those two mps for the id stuff - shall I make a bug report and link it to them, or just put all my explanation into the branch/review description? [11:49] mattyw: i'd just do the latter [13:29] natefinch: here's that change to the voyeur package i mentioned: https://codereview.appspot.com/66000043 [13:30] a fairly small change - reviews appreciated [13:30] rogpeppe: looking [13:30] natefinch: ta [13:35] chris38, go get -u -v launchpad.net/juju-core/... [13:36] dimitern, your script doesn't update src [13:37] chris38, re kvm, its exactly like adding lxc containers .. but with 'lxc' replaced by 'kvm' [13:39] rogpeppe: reviewed [13:39] natefinch: thanks [13:42] rogpeppe, fwereade I've just submitted my first mp for the add|remove user stuff - just the internal stuff so far, the cli will follow shortly - I'm sure there's still work that needs done - but I thought I'd get the ball rolling: https://codereview.appspot.com/61620043/ [13:44] mattyw: i think i've reviewed parts of that before, haven't I? [13:49] hazmat, yep, https://bugs.launchpad.net/juju-core/+bug/1281994 [13:49] <_mup_> Bug #1281994: juju add-machine kvm:0 not working with maas [13:56] hazmat, no, it just rebuilds the binaries [13:58] * rogpeppe goes for some lunch [14:01] rogpeppe, you've looked at it before but not gone as far as commenting on it [14:03] rogpeppe, as far as I remember there was some things that might get moved - but nothing was decided [14:05] chris38, could you attach the machine-0.log to that bug [14:06] chris38, /var/log/juju/machine-0.log [14:08] hatch, yep [14:08] hazmat ^ [14:08] :) [14:08] oops [14:12] hazmat, I update to last juju [14:22] chris38, ok.. but still need the log === natefinch is now known as natef-snowblow [16:04] someday it'll stop snowing every 2 days [16:08] natef-snowblow: warming willing [16:14] I'm enjoying the raft paper: "For example, if message exchanges take longer than the [16:14] typical time between server crashes, candidates will not [16:14] stay up long enough to win an election [16:14] " [16:27] fwereade: i enjoyed the raft paper too [16:27] fwereade: it made me think that it wouldn't be *too* hard to build something as a custom state server backing for juju [16:28] rogpeppe, yeah, that's the direction we're pondering [16:29] fwereade: my inclination was to start by severely cleaning up go-raft [16:29] rogpeppe, I haven't looked at that yet... is it a sorry sight? [16:30] fwereade: it's not *too* bad. but i'd like to see something with a much smaller interface, that doesn't depend directly on disk access [16:31] rogpeppe, isn't storage persistence necessary? [16:31] fwereade: sure, but persistence should be implemented by a pluggable interface, i think [16:32] fwereade: the package interface is about 20 times larger than i'd like to see [16:32] rogpeppe, heh, we often disagree on such issues, but I'll bear that in mind when I look ;) === niemeyer__ is now known as niemeyer [17:46] oh jeeze, *that's* why i'm not seeing log messages - i've imported launchpad.net/loggo, not github.com/loggo/loggo [17:46] argh === _mup__ is now known as _mup_ [18:57] * rogpeppe is done for the day [18:57] g'night all [19:20] hazmat, yippi juju add-machine kvm:0 mostly fixed, indeed it stay the same problem than lxc br0 is not brought up, [19:21] chris38home__, cool, glad you were able to resolve.. it would still be helpful to attach log to bug, .. is it just bridge-utils install early? that's fixed in trunk which it sounds like your using.[ [19:23] I add the interesting part of the lof [19:23] I marked as a duplicate [19:29] hazmat, https://launchpadlibrarian.net/166797169/machine-0.log [19:30] after ssh-ing on the server and sudo ifup br0, server went up [19:33] concerning firewall, I have seen some gpg --recv-key in the code that don't set proxy, which make fail maas installs [19:35] might only be in fast installer [19:37] I build juju on a wheezy box, builds well but I have got [19:37] 2014-02-19 19:37:16 ERROR juju.cmd supercommand.go:294 invalid series "unknown" [19:38] I tried to dig in the code but couldn't find where is this unknown set ? [19:55] chris38home__, its a mapping to image and charm lookup [19:55] chris38home__, probably interpreted from lsb_release === natef-snowblow is now known as natefinch [19:57] thanks, I was suspecting something like that [19:59] If I just add a new Codename it should do the trick [19:59] chris38home__: it's in the version package [19:59] chris38home__: it's in the version package [19:59] chris38home__: see the readSeries function === rogpeppe1 is now known as rogpeppe === mwhudson is now known as zz_mwhudson [20:37] natefinch, hazmat: Is this bug legitimate. Is the use of manual provider wrong? https://bugs.launchpad.net/juju-core/+bug/1282235 [20:37] <_mup_> Bug #1282235: manual provider: juju bootstrap fails with "102 bootstrapping failed, removing state file: exit status 1" [20:46] sinzui: looking [20:50] sinzui: I'm not super familiar with the ins and outs of the manual provider, but that *looks* like it's doing the right thing.... until it fails, obviously. Is there anything useful in the logs on the machine itself? The end of the log in the bug description is unfortunately totally unhelpful === zz_mwhudson is now known as mwhudson [21:08] thank you for your time natefinch === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson [23:39] mwhudson: axw yeah, i'm trying to fix that [23:39] as usual, i've fixed the code but can't make the tests pass