[00:12] <kurt_> marcoceppi_: seeing this error when trying to deploy charm "Requested array, got <nil>."  http://pastebin.ubuntu.com/6211685/
[00:33] <davecheney> omgponies: $UNIT_NAME
[00:33] <davecheney> from memory
[00:33] <davecheney> will check
[00:33] <davecheney> but essentially it'll be an environment variable
[01:00] <davecheney> as I understand it, the http relation interface defines two properties, host and port
[01:00] <davecheney> is this correct (Y/N) ?
[05:00] <styles_> How did you guys like the switch to GoLang?
[06:27] <Kabiigon> hi im am have a lxc issue with a juju install
[06:28] <Kabiigon> lxc fails to start
[06:28] <Kabiigon> fresh install of precise
[06:31] <Kabiigon> serror: net: no such interface
[06:48] <rsynnest> 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] <rsynnest> I'm brand new to IRC as well...
[06:51] <rsynnest> not sure if i can just throw questions out there....
[12:34] <marcoceppi_> kurt_: I think it's safe to ignore, unless the gui didnt' start properly
[14:12] <kurt_> 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 <juju-core:Fix Committed by gz> <https://launchpad.net/bugs/1236734>
[14:13] <marcoceppi_> kurt_: ah, gotchya
[14:14] <kurt_> actually, on closer inspection…may not be that
[14:15] <kurt_> sorry, yes it is…wasn't looking at apache log
[14:15] <kurt_> its listed as critical, so hopefully fix soon
[14:19] <jcastro> marcoceppi_: hey so mramm and I demoed juju at our lug last night
[14:19] <jcastro> and I was talking about horizontal scaling
[14:19] <jcastro> and I did add-unit -n50 as an example
[14:19] <jcastro> "but I wouldn't do that on my laptop with LXC, that's just insane."
[14:20] <jcastro> except I hit enter instead of "next slide"
[14:20] <jcastro> my machine's load is like at 65
[14:20] <mramm> haha
[14:20] <jcastro> so tldr, ctrl-c after a juju command does nothing
[14:20] <jcastro> you're getting -n50 whether you cancelled or not
[14:29] <marcoceppi_> jamespage: yeah, because that's what's up
[14:30] <marcoceppi_> 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 <juju:Fix Committed by hazmat> <juju-core:New> <https://launchpad.net/bugs/1057665>
[14:39] <jcastro> marcoceppi_, I missed the previous line above your response to jamespage
[14:39] <hazmat> 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] <marcoceppi_> jcastro: there was none
[14:49] <hazmat> jcastro, if we can get lxc-clone support with snapshot.. its takes about 0.2s to create a container :-)
[14:49] <hazmat> and about 7m per each
[14:49] <jcastro> hazmat, I think the bottleneck is post container
[14:50] <jcastro> 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] <hazmat> jcastro, true.. most of it is cloud-init based config in terms of time till a juju  unit.
[14:55] <jcastro> http://paste.ubuntu.com/6214069/
[15:12] <jrwren> option to turn that stuff off?
[15:43] <kurt_> LOL bug 1057665
[15:43] <_mup_> Bug #1057665: juju destroy-environment is terrifying; please provide an option to neuter it <juju:Fix Committed by hazmat> <juju-core:New> <https://launchpad.net/bugs/1057665>
[15:44] <hazmat> kurt_, james does beautiful bug descriptions :-)
[15:44] <kurt_> that was pretty funny
[15:46] <kurt_> 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 <juju-core:Fix Committed by gz> <https://launchpad.net/bugs/1236734>
[16:00] <adeuring> marcoceppi_: another MP for charmtools. An one-line change this time
[16:00] <adeuring> marcoceppi_: https://code.launchpad.net/~adeuring/charm-tools/fix-setup-sdist/+merge/190170
[16:00] <marcoceppi_> adeuring: cool, I'll sit on it for several weeks :P
[16:01] <adeuring> ;)
[16:01] <marcoceppi_> adeuring: this actually can be fixed by just having ez_setup.py added to the manifest
[16:01] <marcoceppi_> which isn't commited in the repo
[16:01] <marcoceppi_> :\
[16:02] <marcoceppi_> Oh, nvm, this is even cleaner
[16:02] <adeuring> marcoceppi_: sure, that's the other option
[16:02] <marcoceppi_> adeuring: +1 from me
[16:02] <adeuring> marcoceppi_: thanks!
[16:04] <adeuring> 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] <adeuring> erm, I mean a tarball of charm-tools.
[16:05] <marcoceppi_> adeuring: I just did that :)
[16:05] <marcoceppi_> adeuring: for the brew installer
[16:05] <adeuring> marcoceppi_: great!
[16:05] <marcoceppi_> adeuring: https://launchpad.net/charm-tools/stable/1.0
[16:06] <marcoceppi_> each release will get a tarball going forward, but I might be restructuring the release setup
[16:06] <marcoceppi_> 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] <adeuring> marcoceppi_: ...but running setup.py from that tarball raises "ImportError: No module named ez_setup"
[16:07] <marcoceppi_> adeuring: expect a 1.0.1!
[16:08] <adeuring> marcoceppi_: cool, even better!
[16:58] <marcoceppi_> adeuring: I'm re-arranging the charm-tools release layout, the stable series is going away
[16:58] <marcoceppi_> adeuring: not sure if that breaks anything for you
[16:59] <marcoceppi_> also, 1.0.1 with patched setup.py coming out
[17:00] <adeuring> 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] <marcoceppi_> adeuring: yeah, 1.0.1 will have that new tarball
[17:00] <adeuring> marcoceppi_: sorry, was typing without reading: \o/ for the new release
[17:31] <marcoceppi_> adeuring: https://launchpad.net/charm-tools/1.0/1.0.1/+download/charmtools-1.0.1.tar.gz
[17:31] <adeuring> marcoceppi_: perfect! thanks a lot!
[17:32] <marcoceppi_> 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] <AskUbuntu> how to stop entire openstack so that i can run maas server on my localhost | http://askubuntu.com/q/355914
[17:59] <mhall119> marcoceppi_: it doesn't look like setting that env var is working
[17:59] <marcoceppi_> mhall119: what's the error you're getting?
[18:00] <marcoceppi_> (is it the same as before)?
[18:00] <mhall119> 2013-10-09 17:57:19 INFO juju.worker.uniter context.go:234 HOOK error: no relation id specified
[18:02] <mhall119> marcoceppi_:
[18:02] <marcoceppi_> mhall119: yeah, fun
[18:03] <mhall119> marcoceppi_: JUJU_RELATION_ID=db:1
[18:03] <mhall119> that's what I was prefixing the hook call with
[18:03] <marcoceppi_> mhall119: well, there are two things wrong with that
[18:04] <marcoceppi_> 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] <mhall119> marcoceppi_: I'm getting it dynamically
[18:04] <mhall119> DID=$(relation-ids db)
[18:04] <marcoceppi_> mhall119: ah, cool good
[18:05] <mhall119> then JUJU_RELATION_ID=$DID
[18:05] <mhall119> but I logged ${DID} and it was db:1
[18:05] <marcoceppi_> let me fire up a charm real quick
[18:05] <mhall119> is "db:1" a valid value for JUJU_RELATION_ID?
[18:05] <marcoceppi_> yes
[18:14] <mhall119> marcoceppi_: see line 1847 of http://paste.ubuntu.com/6214819/
[18:15] <mhall119> that's prinding ${JUJU_RELATION_ID}
[18:15] <mhall119> in db-relation-changed
[18:15] <mhall119> 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?
[18:26] <mhall119> marcoceppi_: ?
[18:27] <mhall119> jcastro: I think I broke marco :(
[18:28] <jcastro> hmm?
[18:28] <marcoceppi_> mhall119: sorry, lunching
[18:28] <marcoceppi_> mhall119: will be back in a few :)
[18:29] <mhall119> jcastro: a joke
[18:30] <mhall119> lunch sounds like a good idea though
[18:34] <AskUbuntu> how to run openstack and maas server on localhost together | http://askubuntu.com/q/355931
[19:01] <sinzui> 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 <charmworld:Triaged> <https://launchpad.net/bugs/1237588>
[19:01] <rick_h_> sinzui: sorry, was doing some manual debugging. stagign is having a strange error
[19:02] <rick_h_> bac: think that's you? ^^ doing pdb in the live gunicorn running server? pdb and gunicorn don't place nice
[19:03] <sinzui> 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] <bac> rick_h_, sinzui: i have only been doing passive queries and looking at log files.  not i.
[19:04] <rick_h_> sinzui: yes, this is due to manual monkeying with the source on staging.
[19:04] <rick_h_> 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] <rick_h_> sinzui: reverted changes
[19:06] <sinzui> Thank you rick_h_
[19:07] <rick_h_> sinzui: feel free to ignore that come along before it restarts. Sorry for the noise
[19:08] <sinzui> 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
[19:23] <mhall119> marcoceppi_: so I've tried padding the relation-id with -r to relation-get and now I get:
[19:23] <mhall119> 2013-10-09 19:22:51 INFO juju.worker.uniter context.go:234 HOOK error: no unit id specified
[19:23] <mhall119> :(
[19:24] <marcoceppi_> mhall119: I was afraid of this
[19:25] <marcoceppi_> mhall119: so, in addition to -r <RELATION_ID> you need to specify which unit to pull the data from
[19:25] <marcoceppi_> this is in the format of mysql/0 for example
[19:25] <marcoceppi_> and is set from JUJU_RELATION_UNIT (I think)
[19:25] <marcoceppi_> mhall119: there are way easier ways to manage this stuff
[19:26] <hazmat> marcoceppi_, JUJU_REMOTE_UNIT afaicr
[19:27] <hazmat> mhall119, what's  your context.. if your in a relation hook all this is preset for you...
[19:28] <hazmat> ah config-changed
[19:33] <mhall119> 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] <mhall119> 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] <marcoceppi_> 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 <juju:New> <https://launchpad.net/bugs/1237626>
[20:06] <mhall119> thanks marcoceppi_, I think I have a charm that'll work now
[20:07] <mhall119> jcastro: I still have leftover lxc machine dirs after destroy-environment
[20:07] <jcastro> you will until you upgrade to 1.15.1
[20:07] <mhall119> ah, ok, still have 1.14.1-saucy-i386
[20:08] <jcastro> if you could wait another day or so ....
[20:08] <jcastro> or move to -devel if you want to be risque
[20:09] <mhall119> 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 <juju:New> <https://launchpad.net/bugs/1237634>
[21:43] <adam_g> does juju-core support maas-tags as constraints? as outlined in http://maas.ubuntu.com/docs/tags.html ?
[21:45] <marcoceppi_> adam_g: in 1.15.1 it does
[21:45] <adam_g> marcoceppi_, ah ya just found that
[21:45] <adam_g> marcoceppi_, did i read somewhere that the 1.14.1 -> 1.15.1 upgrade is bumpy?
[21:46] <marcoceppi_> adam_g: there's a bug open about it, have not tried myself
[21:46] <adam_g> marcoceppi_, have the bug # handy? about to try
[21:46] <marcoceppi_> adam_g: 1.16 comes out reallll soon if you want to wait for the next stabl
[21:46] <marcoceppi_> adam_g: https://bugs.launchpad.net/juju-core/+bug/1236622
[21:47] <marcoceppi_> adam_g: 1.16 has the fix for this
[21:48] <adam_g> marcoceppi_, thanks
[22:16] <eagles0513875> fwereade: haha :D now i know where you hid
[22:16] <eagles0513875> hide
[22:16] <eagles0513875> mhall119:  :D
[23:12] <mwhudson> davecheney: hey
[23:12] <mwhudson> oh
[23:12] <mwhudson> unping
[23:12]  * mwhudson hates bash instead of bugging people