=== matsubara-afk is now known as matsubara [08:18] jtv: around? [08:20] jtv: never mind I think I'm OK [08:20] Hi rbasak [08:20] Yes, I'm around. [08:20] Call in 10 minutes though. [08:47] jtv: it was a path issue. HACKING.txt says to run sudo ./scripts/maas-import-isos etc, but those scripts now expect a "maas" comamnd to be in the path. Adding to the local environment doesn't work since sudo doesn't pass it, but sudo PATH=... ./scripts/mass-... worked for me. [08:53] rbasak: I'll update the HACKING.txt to mention that, thanks. [09:05] hey, guys -- is there a maas / juju specific mailing list? === matsubara is now known as matsubara-afk [13:10] after playing with an environment, i destroy it; create a new maas key, and juju boostrap [13:11] now, i reboot the node where zookeper is supposed to be installed, but it s not reprovisionned; no pxe boot reply from the maas server [13:11] it boot on the system already on disk. i can ssh to it, but juju status does not work: [13:11] http://pastebin.com/73jNXbuc [13:11] looks to me zookeper is not "working" (i know nothing about zookeper). How can i get back a juju environment without having to reinstall my whole maas server ? [13:28] Daviey, roaksoax reading above. [13:29] i think that i disagree with the "kernel command line metadata service" [13:29] you can seed some stuff from the kernel command line, but the kernel command line is not idea for passing complex data of any sort. [13:29] (but there is some stuff in cloud-init that could work). [13:30] i'd rather suggest we use the same basic mechanism that is included now. [13:33] smoser: Okay, whatever you suggest.. note, it's only a url that needs to be passed [13:35] the to-be-enlisted node boots with 'url=http://maas/some/default' [13:35] right [13:35] ? [13:36] i hope to ahve that changd to 'cloud-config-url=http://maas/some/enlist' or something [13:36] then that carries payload of really what to do. [14:32] smoser: the extra network hop seems worth it? [15:12] Daviey: roaksoax We just fixed a Critical bug in MAAS' 1.0 branch. Would it be possible for you guys to make release a new version of the package in precise? [15:12] https://bugs.launchpad.net/maas/+bug/1021382 [15:12] Ubuntu bug 1021382 in MAAS "The COMMISSIONING_SCRIPT setting uses a relative path." [Critical,Fix committed] [15:13] s/make release/release/ === matsubara-afk is now known as matsubara [16:18] allenap: no news from Daviey/roaksoax, I'll talk to them on Monday morning first thing. [16:18] * rvba creates a card. [16:19] rvba: Cool. [16:29] i'm here.. but can't talk [16:29] yes, we can do that [16:30] All right then. [16:49] rvba: i'm here what [16:49] s up? [16:49] rvba: oh just saw.. it didn't hightlight me :) [16:49] roaksoax: We fixed a Critical bug in MAAS 1.0. [16:50] rvba: could you open a bug in LP andassign it to me ? [16:50] roaksoax: sure. [16:52] rvba: has this fix also been pushed to quantal? [16:52] err, trunk? [16:53] roaksoax: yes, see the two branches linked to the bug: https://bugs.launchpad.net/maas/+bug/1021382 [16:53] Ubuntu bug 1021382 in MAAS "The COMMISSIONING_SCRIPT setting uses a relative path." [Critical,Fix committed] [16:53] roaksoax: do you really need another bug filed? maybe I could just assign that bug to you? [16:54] rvba: just did. I added a [16:54] rvba: just did. I added a "Also affects distribution" [16:54] Ah, right. [18:33] using MAAS + Juju, where would provider errors be logged on the MAAS side? [18:40] adam_g: should be on /var/log/maas/maas.log [18:41] win 6 [18:48] * robbiew has aquired 10 IPMI cards for our microserver kit....bam! [19:15] robbiew: \o [19:15] robbiew: \o/ [19:15] too bad I don't have them to play with them :( [19:15] heh...me neither [19:15] waiting on shipment to arrive from negronjl :P