[00:12] marcoceppi_: seeing this error when trying to deploy charm "Requested array, got ." http://pastebin.ubuntu.com/6211685/ === CyberJacob is now known as CyberJacob|Away [00:33] omgponies: $UNIT_NAME [00:33] from memory [00:33] will check [00:33] but essentially it'll be an environment variable [01:00] as I understand it, the http relation interface defines two properties, host and port [01:00] is this correct (Y/N) ? === mars is now known as Guest6383 [05:00] How did you guys like the switch to GoLang? === stub` is now known as stub === CyberJacob|Away is now known as CyberJacob === Kab is now known as Percy === Percy is now known as Kabiigon [06:27] hi im am have a lxc issue with a juju install [06:28] lxc fails to start [06:28] fresh install of precise [06:31] serror: net: no such interface [06:48] hey quick random question: i have 12.04 lts and i just installed juju locally with "sudo apt-get install juju-local" before realizing i have LTS and need to install using sudo apt-get install "juju-local linux-image-generic-lts-raring linux-headers-generic-lts-raring" so just wondering if i need to remove anything from that first apt-get? [06:50] I'm brand new to IRC as well... [06:51] not sure if i can just throw questions out there.... === freeflying_away is now known as freeflying === CyberJacob is now known as CyberJacob|Away === exekias_ is now known as exekias === teknico1 is now known as teknico === natefinch-afk is now known as natefinch [12:34] kurt_: I think it's safe to ignore, unless the gui didnt' start properly === vila is now known as vila-laaaate-lun === vila-laaaate-lun is now known as vila-late-lunch === vila-late-lunch is now known as vila === gary_poster is now known as gary_poster|away [14:12] marcoceppi_: I am running in to this: https://bugs.launchpad.net/juju-core/+bug/1236734 [14:12] <_mup_> Bug #1236734: juju 1.15.1 polls maas API continually [14:13] kurt_: ah, gotchya === gary_poster|away is now known as gary_poster [14:14] actually, on closer inspection…may not be that [14:15] sorry, yes it is…wasn't looking at apache log [14:15] its listed as critical, so hopefully fix soon [14:19] marcoceppi_: hey so mramm and I demoed juju at our lug last night [14:19] and I was talking about horizontal scaling [14:19] and I did add-unit -n50 as an example [14:19] "but I wouldn't do that on my laptop with LXC, that's just insane." [14:20] except I hit enter instead of "next slide" [14:20] my machine's load is like at 65 [14:20] haha [14:20] so tldr, ctrl-c after a juju command does nothing [14:20] you're getting -n50 whether you cancelled or not [14:29] jamespage: yeah, because that's what's up [14:30] err jcastro ^ [14:36] <_mup_> juju/trunk r624 committed by kapil@canonical.com [14:36] <_mup_> merge env-safety-belt [14:37] <_mup_> Bug #1057665 was filed: juju destroy-environment is terrifying; please provide an option to neuter it

[14:39] marcoceppi_, I missed the previous line above your response to jamespage [14:39] styles_, there's only one overlap on the devs between the langs on a whole its been nice as a language, and the ecosystem/lib support has come along quite nicely in the last two+ years since the rewrite started. [14:39] jcastro: there was none [14:49] jcastro, if we can get lxc-clone support with snapshot.. its takes about 0.2s to create a container :-) [14:49] and about 7m per each [14:49] hazmat, I think the bottleneck is post container [14:50] like, all of them doing one apt-get update at once, then updatedb/mlocate stuff, update-apt-xapian-index and a bunch of other IO stuff [14:52] jcastro, true.. most of it is cloud-init based config in terms of time till a juju unit. [14:55] http://paste.ubuntu.com/6214069/ [15:12] option to turn that stuff off? === natefinch is now known as natefinch-afk [15:43] LOL bug 1057665 [15:43] <_mup_> Bug #1057665: juju destroy-environment is terrifying; please provide an option to neuter it

[15:44] kurt_, james does beautiful bug descriptions :-) [15:44] that was pretty funny [15:46] Can anyone tell me if you need a guinea pig to test a fix for bug 1236734 ? It's killing me. :D [15:46] <_mup_> Bug #1236734: juju 1.15.1 polls maas API continually [16:00] marcoceppi_: another MP for charmtools. An one-line change this time [16:00] marcoceppi_: https://code.launchpad.net/~adeuring/charm-tools/fix-setup-sdist/+merge/190170 [16:00] adeuring: cool, I'll sit on it for several weeks :P [16:01] ;) [16:01] adeuring: this actually can be fixed by just having ez_setup.py added to the manifest [16:01] which isn't commited in the repo [16:01] :\ [16:02] Oh, nvm, this is even cleaner [16:02] marcoceppi_: sure, that's the other option [16:02] adeuring: +1 from me [16:02] marcoceppi_: thanks! [16:04] marcoceppi_: let's also create a traball for charmworld. We'd like to use the tarball instead of PPAs in charmworld -- makes it easier to maintain the right version. [16:05] erm, I mean a tarball of charm-tools. [16:05] adeuring: I just did that :) [16:05] adeuring: for the brew installer [16:05] marcoceppi_: great! [16:05] adeuring: https://launchpad.net/charm-tools/stable/1.0 [16:06] each release will get a tarball going forward, but I might be restructuring the release setup [16:06] instead of having "stable", it might be based on major version, so there will be a charm-tools/1.0, charm-tools/1.1 series, etc [16:07] marcoceppi_: ...but running setup.py from that tarball raises "ImportError: No module named ez_setup" [16:07] adeuring: expect a 1.0.1! [16:08] marcoceppi_: cool, even better! [16:58] adeuring: I'm re-arranging the charm-tools release layout, the stable series is going away [16:58] adeuring: not sure if that breaks anything for you [16:59] also, 1.0.1 with patched setup.py coming out [17:00] marcoceppi_: no, I don't think so. But I'd appreciate new tar ball. We want to use one for charmworld. (OK, I could also create a new one, but staying in sync seems to be a bit better.) [17:00] adeuring: yeah, 1.0.1 will have that new tarball [17:00] marcoceppi_: sorry, was typing without reading: \o/ for the new release [17:31] adeuring: https://launchpad.net/charm-tools/1.0/1.0.1/+download/charmtools-1.0.1.tar.gz [17:31] marcoceppi_: perfect! thanks a lot! [17:32] adeuring: I've moved the branch structure around a bit too, 1.1 is the current active series of development (lp:~charmers/charm-tools/1.1) I'm still trying to figure out how to best manage a project in lp so bare with me [17:58] how to stop entire openstack so that i can run maas server on my localhost | http://askubuntu.com/q/355914 === CyberJacob|Away is now known as CyberJacob [17:59] marcoceppi_: it doesn't look like setting that env var is working [17:59] mhall119: what's the error you're getting? [18:00] (is it the same as before)? [18:00] 2013-10-09 17:57:19 INFO juju.worker.uniter context.go:234 HOOK error: no relation id specified [18:02] marcoceppi_: [18:02] mhall119: yeah, fun [18:03] marcoceppi_: JUJU_RELATION_ID=db:1 [18:03] that's what I was prefixing the hook call with [18:03] mhall119: well, there are two things wrong with that [18:04] aside from it not working properly, you can't just do a static assignment, the relation_id is created when add-relation happens and it's not easily predictable as to what it will be [18:04] marcoceppi_: I'm getting it dynamically [18:04] DID=$(relation-ids db) [18:04] mhall119: ah, cool good [18:05] then JUJU_RELATION_ID=$DID [18:05] but I logged ${DID} and it was db:1 [18:05] let me fire up a charm real quick [18:05] is "db:1" a valid value for JUJU_RELATION_ID? [18:05] yes [18:14] marcoceppi_: see line 1847 of http://paste.ubuntu.com/6214819/ [18:15] that's prinding ${JUJU_RELATION_ID} [18:15] in db-relation-changed [18:15] but calls in the same script to relation-set and relation-get say no relation id specified, so is having the env variable not enough? === natefinch-afk is now known as natefinch [18:26] marcoceppi_: ? [18:27] jcastro: I think I broke marco :( [18:28] hmm? [18:28] mhall119: sorry, lunching [18:28] mhall119: will be back in a few :) [18:29] jcastro: a joke [18:30] lunch sounds like a good idea though [18:34] how to run openstack and maas server on localhost together | http://askubuntu.com/q/355931 [19:01] rick_h_, jcsackett Do either of you have any ideas why staging.jujucharms.com is sending me hate mail :https://bugs.launchpad.net/charmworld/+bug/1237588 [19:01] <_mup_> Bug #1237588: BdbQuit errors [19:01] sinzui: sorry, was doing some manual debugging. stagign is having a strange error [19:02] bac: think that's you? ^^ doing pdb in the live gunicorn running server? pdb and gunicorn don't place nice [19:03] rick_h_, bac: That sounds much better than having that in trunk. We can mark the bug as a lower priority or invalid if we are certain we cannot release this to production [19:04] rick_h_, sinzui: i have only been doing passive queries and looking at log files. not i. [19:04] sinzui: yes, this is due to manual monkeying with the source on staging. [19:04] I'll mark invalid and make sure to back out my pdb's from earlier. supervisord must have come along and restarted the gunicorn servers and picked up the changes [19:06] sinzui: reverted changes [19:06] Thank you rick_h_ [19:07] sinzui: feel free to ignore that come along before it restarts. Sorry for the noise [19:08] np. I just couldn't understand why I started seeing it. I had this fear something bad was in production and we wont be able to deploy to in until tomorrow === beuno_ is now known as bueno [19:23] marcoceppi_: so I've tried padding the relation-id with -r to relation-get and now I get: [19:23] 2013-10-09 19:22:51 INFO juju.worker.uniter context.go:234 HOOK error: no unit id specified [19:23] :( [19:24] mhall119: I was afraid of this [19:25] mhall119: so, in addition to -r you need to specify which unit to pull the data from [19:25] this is in the format of mysql/0 for example [19:25] and is set from JUJU_RELATION_UNIT (I think) [19:25] mhall119: there are way easier ways to manage this stuff [19:26] marcoceppi_, JUJU_REMOTE_UNIT afaicr [19:27] mhall119, what's your context.. if your in a relation hook all this is preset for you... [19:28] ah config-changed [19:33] hazmat: I'm trying to re-build my db_settings.py for django when a config change results in a new rev of the django code branc [19:33] hazmat: marcoceppi_: I'm going to just copy over the old settings, and let a regular db relation changed updated it when needed [19:34] mhall119: the other idea is to just save the database details to a text file in the $CHARM_DIR and have config-changed read that to update the db_settings [19:56] <_mup_> Bug #1237626 was filed: constraints should be validated [20:06] thanks marcoceppi_, I think I have a charm that'll work now [20:07] jcastro: I still have leftover lxc machine dirs after destroy-environment [20:07] you will until you upgrade to 1.15.1 [20:07] ah, ok, still have 1.14.1-saucy-i386 [20:08] if you could wait another day or so .... [20:08] or move to -devel if you want to be risque [20:09] I can wait, time to ship my charm of to webops [20:10] <_mup_> Bug #1237634 was filed: maas tags support should support full tag syntax [21:43] does juju-core support maas-tags as constraints? as outlined in http://maas.ubuntu.com/docs/tags.html ? [21:45] adam_g: in 1.15.1 it does [21:45] marcoceppi_, ah ya just found that [21:45] marcoceppi_, did i read somewhere that the 1.14.1 -> 1.15.1 upgrade is bumpy? [21:46] adam_g: there's a bug open about it, have not tried myself [21:46] marcoceppi_, have the bug # handy? about to try [21:46] adam_g: 1.16 comes out reallll soon if you want to wait for the next stabl === CyberJacob is now known as CyberJacob|Away [21:46] adam_g: https://bugs.launchpad.net/juju-core/+bug/1236622 [21:47] adam_g: 1.16 has the fix for this [21:48] marcoceppi_, thanks [22:16] fwereade: haha :D now i know where you hid [22:16] hide [22:16] mhall119: :D [23:12] davecheney: hey [23:12] oh [23:12] unping [23:12] * mwhudson hates bash instead of bugging people