[00:00] <m_3> lifeless: cool thanks
[08:51] <shang> hi, anyone knows where I can find more documents on MAAS? like BIOS update, firmware upgrade... etc
[12:12] <hazmat> lifeless, i'm not really understanding what your looknig for re " so, what I'd really like is to be able to shove juju into an lxc and give it a single callback to a 127.0.0.1 only service to fire up more lxc's,  that would let me run multiple juju environments"
[13:22] <jml> hello all
[13:22] <jml> I have a django app that I'm developing that I'd really like to get into a charm
[13:50] <jcastro> jml: mhall119 is working on a django charm generator thing
[13:53] <jml> jcastro: ah thanks. I was sort of hoping to get something up today. noodles pointed me at his blog post (http://micknelson.wordpress.com/2011/11/22/a-generic-juju-charm-for-django-apps/)
[13:53] <jml> I'll work from that and from the bug he linked me to (https://bugs.launchpad.net/charms/+bug/1012942)
[13:53] <_mup_> Bug #1012942: Charm Needed: python-django (with WSGI container) <Juju Charms Collection:New> < https://launchpad.net/bugs/1012942 >
[13:53] <jcastro> http://mhall119.com/2012/06/charming-django-with-naguine/
[14:01] <mhall119> jml: IMO, a single django charm won't work, there's too many different ways to use and deploy django
[14:01] <mhall119> it's more of a library than a service
[14:03] <jml> mhall119: yeah, that makes sense to me
[14:09] <jcastro> SpamapS: ping me when you're around pls
[14:32] <jml> "1) It requires Puppet, which isn’t natural for a Python project" – hah. hah. hah.
[14:32] <SpamapS> jcastro: wassup
[14:32] <jcastro> Hey is juju broken in quantal?
[14:32] <SpamapS> Shouldn't be
[14:33] <SpamapS> evidence?
[14:33] <jcastro> I tried to deploy "ubuntu" but it couldn't find it in the cs:precise/ubuntu, then I realized I forgot I had moved the box to quantal
[14:33] <jcastro> try "juju deploy ubuntu"
[14:33] <jcastro> and juju says it can't find it in the store, it's in the browser though
[14:33] <SpamapS> oh that charm is broken in the charm store
[14:33] <SpamapS> We need to get access to the importer's logs
[14:34] <jcastro> oh ok, so it's not just me, whew
[14:35] <jcastro> SpamapS: ok so I am thinking we should link up mims' jenkins hotness in that "tools" menu on the charm browser
[14:42] <negronjl> 'morning all
[14:44] <bloodearnest> heya all
[14:45] <bloodearnest> am playing with juju on lxc, with mysql<->wordpress<->haproxy and my haproxy isn't working
[14:45] <bloodearnest> I did juju ssh haproxy/0, but I can't find where the haproxy logs are at?
[14:46] <SpamapS> bloodearnest: I don't think haproxy logs much.
[14:46] <bloodearnest> SpamapS, right
[14:46] <SpamapS> bloodearnest: perhaps syslog?
[14:47] <bloodearnest> SpamapS, nothing in there
[14:49] <SpamapS> bloodearnest: I am no haproxy expet, I wrote the charm as a proof of concept.. perhaps the manual will hep in this case?
[14:49] <bloodearnest> also, the juju-generated stanza for proxying to wordpress has this line: server localhost localhost:80 check
[14:49] <SpamapS> s/expet/expert/
[14:49] <bloodearnest> which seems odd
[14:49] <bloodearnest> SpamapS, ok
[14:49] <bloodearnest> I get a 503 with the default config
[14:52] <SpamapS> bloodearnest: yeah it looks like wordpress is using the wrong hostname
[14:52] <bloodearnest> SpamapS, is that an lxc issue?
[14:53] <SpamapS> relation-set port=80 hostname=`hostname -f`
[14:53] <bloodearnest> (i.e. juju on lxc)
[14:53] <SpamapS> no its a charm issue
[14:53] <SpamapS> hostname -f is forbidden ;)
[14:53] <SpamapS> should be `unit-get private-address`
[14:53] <SpamapS> bloodearnest: I'll fix that right now
[14:53] <bloodearnest> SpamapS, sweet
[14:53] <SpamapS> even tho I think we're getting a totally rewritten wordpress charm this week :)
[14:53] <bloodearnest> when will that be available?
[14:53] <bloodearnest> SpamapS, right
[14:54] <bloodearnest> FYI, canonical ISD is having a juju sprint this week, so you might get bugged a bit :)
[14:55] <SpamapS> COOL
[14:55]  * SpamapS shuttles the toddler off to preschool ... bbl
[14:55] <newz2000> I'm with bloodearnest
[14:55] <SpamapS> bloodearnest: fixed in lp:charms/wordpress
[14:56] <bloodearnest> SpamapS, legend, thanks
[14:59]  * mars <- afk, need another cup of tea
[15:10] <newz2000> How do I know if I'm using an updated charm or not?
[15:11]  * newz2000 wants to tryout SpamapS's new wordpress charm
[15:13] <jml> sorry, newbie questions. I've deployed 'python-moin' to lxc on my laptop. How do I get to it?
[15:14] <james_w> jml, you mean to the moin web interface?
[15:15] <jml> james_w: I guess.
[15:15] <jml> james_w: I really mean any actual proof of its upness
[15:15] <james_w> jml, juju status should show an ip address for the "machine" it is running on, hitting that in your browser might be fruitful
[15:15] <jml> james_w: it does noet.
[15:15] <jml>         public-address: null
[15:16] <james_w> jml, what's the full juju status?
[15:16] <jml> http://paste.ubuntu.com/1047479/
[15:17] <james_w> jml, looks like it is still coming up
[15:17] <james_w> agent-state: not-started
[15:17] <james_w> agent-state: pending
[15:18] <jml> oh wow, that does take a while
[15:18] <jml> how can I see progress / get an eta
[15:19]  * jml has taken the garbage out, posted a bunch of thank you letters, cooked and eaten some lamb kebabs, made a request for clearer requirements and checked facebook about 6 times since running 'deploy'
[15:20] <hazmat> jml, ps aux
[15:20] <hazmat> | grep lxc
[15:20] <hazmat> jml, or check the agent log
[15:21] <jml> hazmat: what agent log?
[15:21] <jml> 120       1232  0.0  0.0  25964   840 ?        S    Jun17   0:00 dnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/lxc/dnsmasq.pid --conf-file= --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=lxcbr0
[15:21] <jml> root     27369  0.0  0.0  21156  1032 ?        Ss   14:37   0:00 lxc-start -dn lpdev
[15:21] <hazmat> jml, machine agent log
[15:21] <jml> hazmat: doesn't exist.
[15:21] <hazmat> hmm
[15:25]  * hazmat gets out of meeting
[15:26] <hazmat> jml, so on a broadband connection it shouldn't take more than 15m
[15:26] <hazmat> jml, wrt to logs their in the $data-dir specified in environments.yaml
[15:26] <hazmat> jml, could you  ps aux | grep juju | pastebinit
[15:27] <jml> hazmat: http://paste.ubuntu.com/1047493/
[15:27] <jml> http://paste.ubuntu.com/1047492/ is the contents of my data-dir
[15:28] <hazmat> jml, huh.. did you reboot it?  the machine agent should be logging to /tmp/juju-local/jml-local/machine-agent.log
[15:28] <hazmat> per its cli params
[15:31] <jml> hazmat: "reboot it"? I don't know. When I ran 'juju bootstrap', that failed because the directory was owned by root. So I trashed the existing directory and ran 'juju bootstrap' again
[15:31] <hazmat> jml, ah.
[15:31] <hazmat> jml, you have to destroy-environment after first bootstrap failed..
[15:31] <jml> on the understanding that it didn't conform with the behaviour on CharmSchool so some local thing had probably happened to screw it up, and no one would have told me to store something important in /tmp/, would they?
[15:32] <jml> hazmat: ok. do I do that now? or should I trash it again?
[15:32] <hazmat> jml, yeah. pls destroy-environment, and boostrap again
[15:33] <hazmat> it looks like the previous bootstrap (first) created the machine agent upstart job but never had a place to log to.. but its oddl... it shouldn't care about root perms, because it runs as root to startup the lxc
[15:34]  * jml shrugs.
[15:37] <newz2000> Hmm, had a working config of Wordpress + MySQL, then destroyed everything and started over, now (2x) juju deploy mysql results in agent-state: start-error
[15:38] <newz2000> any idea what's going on here?
[15:38] <newz2000> by everything, I mean all the services, not the environment
[15:38] <bloodearnest> newz2000, did you destro-environment
[15:38] <newz2000> no
[15:39] <newz2000> should I?
[15:39] <bloodearnest> dunno :)
[15:39]  * newz2000 gives it a shot
[15:42] <jml> ok. now I get an IP address in 'juju status', but I can't connect to it (and netstat shows no listening ports on that IP)
[15:45] <jml> jcastro: hey, for my lxc experience should I just paste the backlog here? :P
[15:45] <jcastro> I had a todo to do it this cycle
[15:46] <jcastro> but seeing you today I decided to clear my schedule and just document all the things
[15:48] <hazmat> hmm.. getting the docs reviews are proving difficult
[15:49] <jcastro> it's always the easy ones
[15:52] <mgz> anyone know what getting ConnectionRefusedError in watch_machine_changes on the master is a symptom of?

[15:53] <mgz> juju thinks it launched an instance, but actually didn't, and I don't see anything else of relevence in the juju logs
[15:54] <hazmat> mgz is the service provider responding?
[15:55] <hazmat> mgz,  connection refused would imply it couldn't talk to the provider api endpoint
[15:55] <mgz> it might just be more borked routing in canonistack, I'll check
[15:55] <jml> jcastro: thanks :)
[15:56] <hazmat> mgz, just use something known working.. like hpcloud..
[15:57] <hazmat> special casing canonistack because it doesn't have enough working infrastructure to resemble an openstack deployment feels like its working around the wrong problems
[15:58] <newz2000> SpamapS: I think there might have been a regression in the wordpress charm that was recently updated. Now when I start an instance I get "it works!"
[15:59] <mgz> bah, I know what it is... the routing actually works inside, but my local workaround is getting on to the provider and breaking it
[15:59] <newz2000> SpamapS: oh, wait, i forgot to expose it
[15:59] <fugue88> newz2000: That's the wp-config.php thing I mentioned.
[15:59] <fugue88> fugue88: So, maybe a problem with the wordpress charm not expecting to have different hostnames passed into it.
[15:59] <newz2000> SpamapS oh, that didn't change it. Still "it works!"
[15:59] <fugue88> But not a problem with the haproxy charm.
[16:00] <newz2000> fugue88: yes, but I'm just hitting the wordpress IP
[16:00] <newz2000> not using haproxy or anything yet
[16:00] <mgz> hazmat: where does the conf get stored on the master?
[16:01] <hazmat> mgz, conf?
[16:04] <mgz> hazmat: as in, it's not in /home/ubuntu/.juju/environments.yaml but was serialised and passed across somewhere
[16:04] <hazmat> mgz its in zk
[16:04] <mgz> dammit :)
[16:04] <hazmat> mgz /usr/share/zookeeper/bin/zkCli.sh
[16:04] <hazmat> mgz interactive console ls /    .. get /environment
[16:05] <mgz> ta, poking.
[16:09] <hamptonpaulk> ping SpamapS
[16:10] <jml> mhall119: why does naguine think my django project uses sqlite3?
[16:12]  * SpamapS is back
[16:13] <SpamapS> newz2000: the wordpress charm is broken w.r.t. hostnames
[16:13] <SpamapS> newz2000: I thought I had fixed it so the "default" host was wordpress tho
[16:13] <mgz> well this is daft, java.lang.NumberFormatException on setting any string with a space in it...
[16:13] <newz2000> SpamapS: I see! I think this is somewhat inherited from the debian package
[16:13] <mgz> must be a way of passing content of a file
[16:14] <newz2000> SpamapS I think I've foobar'd my juju setup so take my current feedback with a grain of salt.
[16:15] <SpamapS> newz2000: well when in doubt, destroy and re-deploy :)
[16:15] <newz2000> SpamapS: I've just done that and now I can't successfully deploy mysql. Gonna do dist-upgrade and reboot. Then I'll test and get back to you.
[16:17] <hazmat> jcastro, fixed re docs in review queue
[16:17] <jcastro> <3
[16:18] <hazmat> although the display could use some work
[16:18] <jcastro> oh, those are core branches
[16:19] <hazmat> jcastro, no their doc branches
[16:19] <hazmat> just displayed badly
[16:19] <jcastro> oh
[16:19] <jcastro> oh nice, so really, more good targets then
[16:20] <hamptonpaulk> ping SpamapS: I believe I am having an issue with https://bugs.launchpad.net/juju/+bug/920454 - is there currently a workaround of any sort?
[16:20] <_mup_> Bug #920454: juju bootstrap hangs for local environment under precise on vmware <local> <juju:Confirmed> < https://launchpad.net/bugs/920454 >
[16:21] <hazmat> jcastro, fixed
[16:52] <mgz> sorry to everyone who's about to get a very large diff in email.
[16:52] <bloodearnest> SpamapS, I think the issue w/wordpress is when putting haproxy in front - forwarded hostname is different so fails to find the right config in /etc/wordpress
[16:53] <marcoceppi> bloodearnest: that is a known issue with the current charm
[16:53] <hazmat> mgz, woot!
[16:54] <bloodearnest> marcoceppi, k thanks, got a bug I can watch?
[16:54] <marcoceppi> let me find it
[16:55] <jcastro> ooh happy, there's the openstack provider incoming, woo!
[16:58] <robbiew> woot!
[16:58] <mgz> :)
[16:58] <SpamapS> marcoceppi: are you done w/ the new one yet?
[16:58] <marcoceppi> SpamapS: not yet, should be done with it this week
[16:58] <SpamapS> marcoceppi: let me rephrase that. Does the new one work for even the most basic use case yet?
[16:59] <mhall119> jml: does it say it uses sqlite in your settings.py?
[16:59] <SpamapS> marcoceppi: at this point, I'd rather have "not done but actually works sort of" over "thing that basically doesn't work at all"
[16:59] <marcoceppi> SpamapS: It's not at the point where I'd feel comfortable having people used it. A lot of stuff is still being shuffled around in it
[17:00] <marcoceppi> and the subordinate isn't even anywhere near operational yet
[17:00] <jml> mhall119: oh right. I thought I'd blatted over that, but I was getting confused with a different project.
[17:00] <SpamapS> marcoceppi: mmk. :-/
[17:00] <marcoceppi> yeah
[17:04] <bloodearnest> SpamapS, I think your earlier change fixed this bug - or at least it did for me https://bugs.launchpad.net/charms/+source/wordpress/+bug/903312
[17:04] <_mup_> Bug #903312: Inocorrect Server is specified in Haproxy when using haproxy with Local Provider <wordpress (Juju Charms Collection):New> < https://launchpad.net/bugs/903312 >
[17:05] <SpamapS> bloodearnest: right. Not sure if that will fix the haproxy issue
[17:06] <SpamapS> bloodearnest: if it does though, huzzah
[17:07] <bloodearnest> SpamapS, the hazproxy works correctly, but the wordpress doesn't :)
[17:08] <SpamapS> right
[17:09] <SpamapS> man.. the old wordpress charm kind of sucks (no offense to the authors). I think it might have been *the first charm ever written* .. but.. we've learned so much since then
[17:09] <bloodearnest> marcoceppi, is this the bug in question? https://bugs.launchpad.net/charms/+source/wordpress/+bug/958204
[17:09] <_mup_> Bug #958204: Apache doesn't know about the server's private address <wordpress (Juju Charms Collection):Confirmed> < https://launchpad.net/bugs/958204 >
[17:09] <marcoceppi> bloodearnest: that's it
[17:10]  * SpamapS does a little cleaning up even tho marco is days away from fixes
[17:10] <hamptonpaulk> SpamapS: did you happen to see the above question about Bug #920454? Switching away from vmware for the time being, just would love any input you may have.
[17:10] <_mup_> Bug #920454: juju bootstrap hangs for local environment under precise on vmware <local> <juju:Confirmed> < https://launchpad.net/bugs/920454 >
[17:10] <bloodearnest> marcoceppi, kk, thx
[17:11] <bloodearnest> SpamapS, is "what you've learned since then" documented anywhere?
[17:11] <bloodearnest> :)
[17:11] <marcoceppi> bloodearnest: there are a series of posts that outline what we've learned (and it was oh so much) but the best documentation is the next release of the charm
[17:11] <SpamapS> bloodearnest: sadly no, we have a lot of work to document those best practices
[17:12] <SpamapS> marcoceppi: I'm not even talking about that
[17:12] <SpamapS> just basic stuff
[17:12] <SpamapS> like what to do in install vs. config-changed
[17:12] <marcoceppi> SpamapS: oh yeah, sadly there isn't a like charming 101 kind of post
[17:12] <bloodearnest> marcoceppi, is the next version available for instruction purposes?
[17:12] <SpamapS> we don't need posts
[17:13] <SpamapS> we need books really
[17:13] <SpamapS> We should mirror the upstart cookbook
[17:13] <SpamapS> or rather, follow its model
[17:13] <marcoceppi> the upstart cookbook is huge though
[17:13] <SpamapS> If I want to do X, do it this way. If I want to do Y, do it that way.
[17:13] <marcoceppi> and I found it difficult to navigate btw
[17:14] <SpamapS> Hrm thats a bummer.
[17:14] <marcoceppi> bloodearnest: it's really not ready yet (to the point that it doesn't run at all without lots of interventions) but that's because it's mid-refactor
[17:14] <marcoceppi> SpamapS: I agree that there should be a resource for this though
[17:15] <marcoceppi> I really like how Go does their intro to Go http://tour.golang.org/#1
[17:15] <marcoceppi> Not sure how it could be adapted to Charming though
[17:16] <bloodearnest> marcoceppi, kk - we're going to be writing a bunch of charms in order to a) learn how to and b) hopefully charmify Ubuntu SSO/Pay  so that kinda stuff (best practice, what to do where) would be useful
[17:16] <SpamapS> marcoceppi: a tour would actually be fantastic
[17:16] <SpamapS> We kind of do i for juju usage in all our talks
[17:17] <marcoceppi> I think a tour for juju would be boss
[17:17] <SpamapS> s/ i / it /
[17:17] <SpamapS> hmmmm whats this then https://code.launchpad.net/~gz/juju/openstack_provider/+merge/110860
[17:17] <marcoceppi> but since charms are all so, unique - it's hard to be like HERE'S A TOUR OF CHARMING, but it's in bash - or it's all in python - or it's all in C#
[17:17] <marcoceppi> SpamapS: Oh, hello there
[17:18] <SpamapS> marcoceppi: we're like construction workers who just saw Charlize Theron walk by in a sun dress.. ;)
[17:19]  * marcoceppi whistles loudly
[17:31]  * SpamapS gets tired of chasing local provider fail and goes back to EC2.. again
[17:35]  * avoine can't wait to test the new OpenStack provider
[17:35] <jcastro> SpamapS: heh ... yeah
[17:37] <SpamapS> avoine:  should be able to test it just by branching that
[17:37] <avoine> I'm looking at the diff now
[17:37] <avoine> I'll do that
[17:40] <jcastro> negronjl: mira, around today?
[17:41] <negronjl> jcastro: here ... working on the Structure/MaaS/Juju thing
[17:41] <jcastro> SpamapS: hey so we were missing the docs submissions in the queue, hazmat fixed it, check out the review queue now!
[17:41] <jcastro> negronjl: oh, so not a good time to ask about graphs then
[17:41] <SpamapS> /tmp/juju-createRVPUAG: line 28: /etc/resolvconf/run/resolv.conf: No such file or directory
[17:41] <negronjl> jcastro:  lol ... not yet ...
[17:41] <SpamapS> anybody else see this while trying to use local provider?
[17:41] <jcastro> negronjl: we should G+ with m3 later today though, talk velocity?
[17:42] <SpamapS> oh wait, n/m .. needed latest juju
[17:43] <negronjl> jcastro:  sure ...
[17:44] <negronjl> jcastro: let me know when  .... I also have the Ubuntu Developer Contributor thing today in about 1 hour and 15 minutes or so
[17:44] <jcastro> oh ok
[17:45] <jcastro> we can punt to tomorrow if you want
[17:45] <negronjl> jcastro: better
[17:52] <SpamapS> kees: FYI, just merged all of lp:~kees/charms/precise/mumble-server/trunk into lp:charms/mumble-server. Thanks for adding maintainer. :)
[17:56] <hazmat> jcastro, there mouseovers for the origin branch name fwiw on the merges
[17:56] <hazmat> argh. their
[17:56] <hazmat> they're
[17:56]  * hazmat finds a new language
[18:03] <kees> SpamapS: thanks! I've got an update for my 'sbuild' charm as well, if you want to snag that oo.
[18:03] <kees> *too
[18:04] <SpamapS> kees: \o/
[18:04] <SpamapS> I think we're down to 20 that need maintainers
[18:04]  * SpamapS needs to pick that torch back up.. 
[18:06] <kees> SpamapS: note that the sbuild charm is more than just maintainer addition -- it's a refresh for precise, and makes the confg control better.
[18:08] <SpamapS> kees: excellent. I tend to just accept anything from maintainers that doesn't introduce malware. :)
[18:08] <kees> SpamapS: \o/
[18:09] <SpamapS> I figure if you're willing to put your name on it, you are willing to hear from angry users :)
[18:09] <kees> hehe
[18:11] <kees> SpamapS: I did it as a normal bug rather than a merge request because I didn't realize the oneiric charms all got moved forward to precise
[18:12] <SpamapS> kees: yeah we're still figuring out how thats going to work long term anyway.
[18:12] <SpamapS> Looking more and more like it will work a lot like the distro, except with aggressive backporting for new stuff.
[18:16] <kees> SpamapS: cool
[18:18] <SpamapS> hazmat: trying to test out local provider + proposed .. seems like juju-create is getting cached somewhere
[18:18] <SpamapS> hazmat: any ideas where that might be?
[18:18] <hazmat> SpamapS, its the first container in the env
[18:18] <hazmat> SpamapS, lxc-ls
[18:18] <SpamapS> hazmat: destroyed and bootstrapped.. should be gone right?
[18:18] <hazmat> yes
[18:37] <pindonga> SpamapS, hi there, so I'm playing a bit with juju, done the basic wordpress stuff bla bla
[18:37] <pindonga> so next I added an haproxy in front of the wordpress instance (so I can later on add more units there)
[18:37] <pindonga> and I know wordpress charm doesn't play very nicely along with the haproxy one
[18:38] <pindonga> and I know you guys are about to rewrite everything , so this is not a support request :)
[18:38] <pindonga> except for some help in understanding the charm
[18:38] <SpamapS> pindonga: sure, I'm looking at it right now also so.. :-P
[18:38] <pindonga> I see haproxy requires the other service to provide a reverseproxy relation
[18:38] <pindonga> which wordpress doesn't do
[18:39] <pindonga> so I was trying to make wordpress expose such a relation
[18:39] <pindonga> for that I just need to edit the metadata and provide a reverseproxy-relation-{joined,changed} hooks right?
[18:39] <pindonga> in the wordpress charm
[18:40] <SpamapS> err
[18:40] <SpamapS> no you' have it backwards
[18:40] <pindonga> ah :)
[18:40] <pindonga> hence the question
[18:40] <SpamapS> haproxy requires the other service to have an *http* relation
[18:40] <SpamapS> which nearly all the webapps in the charm store do
[18:40] <SpamapS> the name, reverseproxy, is irrelevant outside the hooks dir
[18:40] <pindonga> ah, and it names that http relation 'reverseproxy'
[18:40] <SpamapS> well irrelevant to the other side I should say
[18:41] <pindonga> k
[18:41] <SpamapS> pindonga: haproxy names it reverseproxy. Most charms name the provider side 'website'
[18:41] <pindonga> kk
[18:41] <SpamapS> that interface.. http.. is very "proof of concept" .. we need to work out something better
[18:42] <pindonga> so, the idea I had was that when the relation gets established we just symlink /etc/wordpress/config-<haproxy-ip>.php -> /etc/wordpress/config-<local ip>.php
[18:42] <pindonga> that would make it work (for my purposes)
[18:42] <pindonga> so I need to add that to the "something"-relation-{joined,changed} hook on wordpress right?
[18:43] <SpamapS> pindonga: I believe there's a "default" possible as well
[18:43] <SpamapS> pindonga: which is what should be done
[18:44] <SpamapS> pindonga: but yes for your purposes.. I'd add that link wherever the main config-... is made
[18:44] <pindonga> I am just checking
[18:44] <pindonga> the main config is created during db-relation-changed
[18:45] <pindonga> however that's not where this should happen
[18:45] <lifeless> hazmat: I'm here if you want me to expand on what I said
[18:45] <pindonga> the extra symlink would then happen when website-relation-changed probably
[18:45] <pindonga> SpamapS, thanks, I'll try it out and let you know
[18:46] <SpamapS> pindonga: yes that would work
[18:46] <SpamapS> pindonga: website-relation-joined would be fine actually
[18:46] <SpamapS> pindonga: you'll have the public-address at that point
[18:46] <SpamapS> which is what you want
[18:46] <pindonga> yep,
[18:46] <SpamapS> tho I think changed is "more correct"
[18:46] <SpamapS> since in the future, that may change
[18:46] <pindonga> it needs to happen in both
[18:46] <pindonga> probably
[18:47] <SpamapS> pindonga: changed is always called once after joined no matter what
[18:47] <SpamapS> so, just in changed is appropriate
[18:47] <pindonga> ah, good to know
[18:47] <pindonga> is that documents in the hooks page?
[18:47] <pindonga> s/documents/documented/
[18:49] <SpamapS> pindonga: https://juju.ubuntu.com/docs/charm.html#hooks
[18:49] <pindonga> yep, thx
[18:50] <hazmat> lifeless, awesome
[18:50] <hazmat> lifeless, so  i saw rabbitmq queues and pika clients to juju..
[18:50] <lifeless> hazmat: huh... ?
[18:51] <hazmat> lifeless, sorry.. crossed the streams that was ted
[18:51] <hazmat> lifeless, what are you trying to do?
[18:52] <lifeless> me, I had a chat with m_3 and filed a bug as a result, about juju's degree of entanglement with my machine, for the 'local' provider.
[18:52] <lifeless> its much more intrusive than I had anticipated
[18:52] <hazmat> lifeless, the upstart job, and the libvirt network?
[18:52] <lifeless> to the extent it won't work on half my machines here, and will duplicate basic functionality like my squid cache
[18:52] <lifeless> hazmat: running apt-cacher-ng, running zookeeper
[18:53] <lifeless> hazmat: the latter, AIUI, constraining me to one local environment at a time
[18:53] <hazmat> lifeless, it doesn't
[18:53] <hazmat> lifeless, we run each env's zk on an offset port
[18:53] <hazmat> er. random port
[18:53] <hazmat> listening on the bridge i believe
[18:54] <lifeless> ah, well thats something; however my lxc bridge is bridged to my LAN :)
[18:55] <SpamapS> it uses the libvirt default network
[18:55] <SpamapS> not the lxcbr
[18:56] <lifeless> sorry for being imprecise.
[18:56] <lifeless> I have a grunty workstation. its what I run $stuff on.
[18:57] <lifeless> to make getting at its kvms and lxcs easy, its libvirt bridge is my LAN.
[18:57] <SpamapS> yeah, thats a bug that needs fixing for sure.. should allow an option to override the default network
[18:58] <lifeless> how is the traffic securing work coming? I presume its trusted-traffic at the moment still ?
[18:59] <hazmat> lifeless, demo of multiple local envs.. fwiw http://paste.ubuntu.com/1047850/
[19:00] <hazmat> lifeless, so transport level nothing yet
[19:00] <hazmat> lifeless, securing zk storage, i've hit a libzk issue, i need to debug, getting some deadlocks
[19:01] <hazmat> re transport i don't see much outside of stunnel  or a twisted tls proxy.
[19:01] <hazmat> lifeless, that's wrt to zk communication.. machine level security we need to switch out to firewalls. etc
[19:01] <lifeless> hah https://issues.apache.org/jira/browse/ZOOKEEPER-235
[19:01] <SpamapS> hazmat: heh, figured out my proposed+local issue.. r542 incoming. ;)
[19:01] <lifeless> :( sadface.
[19:02] <hazmat> lifeless, yeah..
[19:02] <hazmat> lifeless, there are people who run it with stunnel over untrusted networks.. but its a serious issue.
[19:02] <lifeless> and yay, dup : https://issues.apache.org/jira/browse/ZOOKEEPER-1000
[19:02] <lifeless> hazmat: I agree :>
[19:02] <hazmat> lifeless, atm, most of the developer bodies are on gojuju
[19:03] <lifeless> hazmat: so, what does juju bootstrap locally do - adds an upstart job which runs apt-cacher-ng + zk, creates a single seed lxc node ?
[19:03] <pindonga> SpamapS, if you don't mind one more question, I'm trying to debug the relation-changed hook... I exported the environment settings (JUJU_UNIT_NAME, JUJU_RELATION, JUJU_REMOTE_UNIT) but it's saying JUJU_AGENT_SOCKET is not set... how can I debug the relation-changed hook?
[19:03] <hazmat> lifeless, install apt-cacher-ng, upstart job for machine agent, and upstart job for a simple file storage
[19:03] <SpamapS> pindonga: juju debug-hooks servicename/# is the best way
[19:04] <pindonga> SpamapS, I'm in there
[19:04] <lifeless> hazmat: any way to tell it to shove off w.r.t. apt-cacher-ng ? I have caching already :)
[19:04] <hazmat> lifeless, on adding the first service, it creates an lxc container that it customizes and uses as a template for deploying units
[19:04] <pindonga> but now I went to where the hook is stored, and run it (following the tutorial)
[19:04] <pindonga> however I get these errors
[19:04] <hazmat> lifeless, atm no.
[19:04] <pindonga> while it tries to run unit-get and relation-get
[19:05] <lifeless> hazmat: and there is something that restarts units on laptop reboot, I believe? Where does that live ?
[19:05] <hazmat> lifeless, there is not .. local envs are toast on restart
[19:05] <hazmat> local provider has not seen much love
[19:06] <lifeless> hazmat: toast == not running or toast == deleted ?
[19:06] <hazmat> lifeless, not running
[19:06] <lifeless> hazmat: how do you cleanup such an environment?
[19:06] <lifeless> or restart it ?
[19:06] <SpamapS> pindonga: no you have to wait till the hook is executed, you can't just force it
[19:06] <hazmat> lifeless, juju destroy-enviornment
[19:06] <SpamapS> pindonga: remove/add the relation
[19:06] <SpamapS> pindonga: you'll get a new tmux window per hook execution
[19:06] <lifeless> hazmat: is it possible to restart it ?
[19:06] <pindonga> SpamapS, so before I do that: I run debug-hooks and it opened the ssh session to my unit
[19:06] <pindonga> that's ok?
[19:06] <pindonga> SpamapS, now I remove/add the relation, yes?
[19:06] <SpamapS> pindonga: thatss exactly right
[19:07] <pindonga> SpamapS, thx, sorry for the noise
[19:07] <pindonga> :)
[19:07] <SpamapS> pindonga: no, thanks for the noise. :)
[19:07] <hazmat> lifeless, you'd have to start zk, and the containers
[19:07] <hazmat> the zk is not upstartified
[19:07] <hazmat> neither are the env containers
[19:08] <pindonga> SpamapS, didn't do anything afaict
[19:08] <pindonga> just did juju remove-relation but it finished
[19:08] <pindonga> same for add-relation
[19:08] <pindonga> or do I have to run these from within the unit I got opened via debug-hooks?
[19:08] <lifeless> so, the heart of my bug was, I guess, that we're special casing LXC more than we need to - doing a -tiny- cloud api for local use should be doable as a standalone project, and that would let 'local' have nothing special to do.
[19:09] <hazmat> lifeless, agreed..
[19:09] <lifeless> Said cloud API could remember state like 'this lxc was running' as well.
[19:09] <hazmat> lifeless, SpamapS made the original lxc provider that way
[19:09] <hazmat> but it didn't fly for what are at this point histerical raisons
[19:10] <lifeless> so local juju config would become, install lxc-cloud-api, create a user, put user details in environments.yaml, profit. Install a cache and configure that in environments.yaml if you need one.
[19:10] <hazmat> the other delta for the local provider is that its too intimate with its customization of the container
[19:10] <hazmat> it should use cloud init and cloud-images ala every other provider
[19:10] <hazmat> that's what lp:~hazmat/juju/local-cloud-img is a start on (the latter)
[19:10] <lifeless> yeah
[19:10] <SpamapS> pindonga: when the window opens, you have to run the hook yes
[19:10] <lifeless> is it worth someone writing such a local cloud API ?
[19:11] <SpamapS> pindonga: the idea is that you can run it with debuggers or strace or whatever
[19:11] <pindonga> SpamapS, ah, sorry, I think I start to understand
[19:11] <pindonga> wasn't seeing the fact that it's a screen session
[19:11] <SpamapS> or just run it over and over fixing it :)
[19:11] <pindonga> and it's opening up more tabs
[19:11] <hazmat> lifeless, hmm.. interesting as a separate project?
[19:11] <hazmat> or as a new local provider impl?
[19:12] <lifeless> separate project.
[19:12] <lifeless> It clearly has nothing to do with juju.
[19:12] <lifeless> arguably its related to libvirt in fact
[19:12] <SpamapS> libvirt has lxc
[19:12] <lifeless> yes
[19:13] <lifeless> I don't think libvirt has a securable HTTP(s) interface though, no ?
[19:13] <hazmat> lifeless, it has a net api
[19:13] <SpamapS> sure, its called OpenStack :)
[19:13] <hazmat> that too ;-)
[19:13]  * m_3 would love to see a libvirt provider
[19:13] <SpamapS> a bit heavy tho
[19:13] <pindonga> SpamapS, , now when I run the add-relation command, I see this in the debug-hooks window: [wordpress 0:bash- 1:website-relation-broken*   ...
[19:13] <lifeless> SpamapS: 'bit'.
[19:13] <pindonga> SpamapS, however I can't change tabs, like with pure screen (ctrl-a 0, ctrl-a 1)
[19:14] <marcoceppi> So now that Openstack provider support is almost done, when are we going to see Azure :)
[19:14] <SpamapS> pindonga: if it doesn't exist, you can just exit the shell
[19:14] <hazmat> lifeless, i'd eschew libvirt.. seems reasonable though
[19:14] <SpamapS> pindonga: its not screen, it is byobu
[19:14] <lifeless> SpamapS: thats like 'I had a 'bit' too much to drink at UDS'
[19:14] <hazmat> marcoceppi, tbd, but don't hold your breath
[19:14] <SpamapS> pindonga: and I think its tmux byobu
[19:14] <marcoceppi> hazmat: ;)
[19:14] <pindonga> ah, now I exited that and it came up again with website-relation-joined (so this was actually queued up waiting for the other hook)
[19:15] <pindonga> SpamapS, k, starts to make sense (a bit weird, but progress :))
[19:15] <SpamapS> lifeless: well we did do the hat, and the nose.. but she has got a wart..
[19:15] <lifeless> :>
[19:16] <lifeless> SpamapS: seriously though, would running nova + swift locally really be appropriate here? Seems like they have massive overkill.
[19:16] <SpamapS> lifeless: they do. You'd have to spin up a container just for them.
[19:16] <lifeless> even if nova grows lxc backend support, you're looking at a pretty tall stack once you bring up its message bus, authentication etc.
[19:17] <SpamapS> nova has lxc support already
[19:17] <lifeless> ok, nice to know.
[19:17] <SpamapS> nova also has grown 0mq support, so rabbit can be disposed of at least
[19:17] <SpamapS> and sqlite can be used for the db
[19:17] <lifeless> 0mq is still a queue :P
[19:17] <SpamapS> lifeless: but its a peer to peer queue, and in a local setting can be defaulted to localhost :)
[19:18] <lifeless> SpamapS: I'm not sure if you're saying 'its a good idea' or 'technically feasible but I still wouldn't like to do it'
[19:18] <SpamapS> I'm hashing it out in my head, and dumping the results in here
[19:18] <SpamapS> no goal
[19:18] <lifeless> fair enough
[19:18] <lifeless> While you do that, I'm going to go get cynthia out of bed
[19:18] <SpamapS> I should probably eat actually. :)
[19:19]  * SpamapS goes looking for the Truck Norris gourmet burger truck
[19:19] <SpamapS> they're spicy.. just a little KICK
[19:25] <negronjl> SpamapS: what happened to that diet thing you were going for ? :)
[19:26] <m_3> gourmet burgers are diet... right?  huh?
[19:27] <lifeless> negronjl: did you get hold of moser ?
[19:27] <lifeless> (and good morning :P)
[19:33] <negronjl> lifeless:  yup ... I've been working with a few guys on this already ..
[19:34] <negronjl> lifeless:  I'm at #ubuntu-meeting atm ... trying to get Ubuntu Contributing Developer ... brb
[19:38] <negronjl> lol ... denied Ubuntu Contributing Developer .... AGAIN
[19:38] <negronjl> I must really suck at this
[19:38] <m_3> negronjl: no way!
[19:39] <negronjl> m_3: yup ... denied
[19:40] <m_3> dang, I was thinking of going up before long... maybe I'll rethink that
[19:40] <negronjl> My juju contributions don't count
[19:40] <negronjl> this is the second time i try this ... no more.
[19:41] <m_3> man, that sucks
[19:54] <pindonga> is it possible to call upgrade-charm using a different repository than the one you used for the original deploy?
[19:54] <pindonga> I get an error when doing so
[19:55] <pindonga> I've installed a charm from the charm store, and now I want to upgrade it from a local repo
[19:55] <pindonga> for toying around
[20:03] <SpamapS> pindonga: heh, there's a bug for that
[20:03] <SpamapS> pindonga: IMO the charm store is inherently broken until we have a 'switch-charm' command
[20:04] <hazmat> jimbaker, fwiw you've got a couple of approved doc merge proposals that have been sitting around for  a while
[20:04] <hazmat> http://jujucharms.com/review-queue
[20:04] <pindonga> SpamapS, so you actually recommend deploying everything from a local repo?
[20:05] <pindonga> is there a workaround for that bug, or do I have to recreate my instances from a local charm repo?
[20:06] <pindonga> and is it possible to add the local repo as the default option so I don't have to constantly pass in the --repository option?
[20:08] <SpamapS> pindonga: I do
[20:08] <SpamapS> pindonga: export JUJU_REPOSITORY=/home/you/charms :)
[20:09] <SpamapS> pindonga: you can't convert a service unit from one charm to the other, but if you're using ec2, you can destroy the service, and re-deploy onto the same machines. However, some charms will break on that.
[20:10] <pindonga> SpamapS, I'm doing it locally, and have just done that
[20:10] <pindonga> :)
[20:10] <pindonga> thx for the env var
[20:11] <pindonga> the only problem with local is that it's slow :) (on my machine)
[20:11] <pindonga> but other than that it works , which is already a long way to go
[20:12] <SpamapS> pindonga: I agree.. SSD helps a lot
[20:12] <pindonga> I'm actually cheating against myself...
[20:12] <pindonga> running juju inside of a qemu-kvm vm deploying to lxc instances inside of that, and all of that on a laptop 7200rpm disk
[20:12] <pindonga> can't expect it to be too fast :)
[20:13] <SpamapS> yeah even natively it will suck though ;)
[20:13] <pindonga> so, out of curiosity, what are the plans to support multiple services per host machine?
[20:13] <jimbaker> hazmat, true, i will move those into an appropriate specs directory in the docs
[20:14] <SpamapS> I'm not sure "specs" is right
[20:15] <SpamapS> Perhaps just headers saying that a spec is unimplemented
[20:17] <jimbaker> SpamapS, but these specs are implemented in this case
[20:17] <SpamapS> jimbaker: well in that case its just regular documentation
[20:17] <jimbaker> SpamapS, they just are not great for actual docs
[20:18] <SpamapS> jimbaker: whats the point of them then?
[20:19] <jimbaker> SpamapS, they do describe the implemented behavior. but they are not user friendly imho. on the other hand, maybe they are the first pass of what should be cleaned up for that purpose
[20:19] <jimbaker> SpamapS, however we do have some other internals oriented docs in juju docs, assuming they're still around
[20:19] <SpamapS> jimbaker: users need to have defined behavior before they need to have easy to read behavior definitions :)
[20:20] <jimbaker> SpamapS, right :)
[20:28] <SpamapS> Ok, I just pushed a fix to wordpress in the charm store which makes it the only thing on port 80
[20:28] <SpamapS> which, consequently, makes it work w/ haproxy
[20:29] <SpamapS> marcoceppi: no, I dare you to make that fix irrelevant :)
[20:29] <pindonga> SpamapS, cool, I'll try it out
[20:29] <pindonga> however I'll first make sure I get it working locally via another way (to learn charms better)
[20:30] <SpamapS> make sure you have bzr rev54, or charm rev 34
[20:33] <marcoceppi> SpamapS: well...it technically wont' work with multisite, but since you can't really expose/configure that with the current charm I guess that makes it okay :P
[20:38] <SpamapS> marcoceppi: right, multi-site is a whole other thing
[20:39] <marcoceppi> SpamapS: new charm will support it, with site-specific subordinates
[20:39] <SpamapS> marcoceppi: thats great... like I said, make my change irrelevant :)
[20:39] <marcoceppi> It'll be hard, but I'll try not to :P
[20:57] <pindonga> SpamapS, final question of the day
[20:58] <pindonga> so my hook is trying to do a sed on an apache config file, however, from the hook itself I cannot read that file, but in the shell from debug hooks I can
[20:58] <pindonga> ie, ls -l /etc/apache/sites-enabled shows the file, but doing cd /etc/apache/sites-enabled within the hook gives me an error
[21:01] <SpamapS> pindonga: thats a bit odd, but is it possible you're trying to edit it before apache is installed?
[21:01] <SpamapS> pindonga: also it should be /etc/apache2
[21:02] <pindonga> SpamapS, no, it was me not reading carefully enough
[21:02] <pindonga> :/
[21:02] <pindonga> sorry, and thanks
[21:02] <pindonga> it worked now
[21:02] <pindonga> s/apache/apache2/
[21:03] <pindonga> cool, my charm now works with haproxy \o/
[21:03] <pindonga> SpamapS, what I did was to add a website-relation-changed hook and inside there I do 3 things
[21:03] <pindonga> 1. sed the apache config to include ServerAlias ${remote_ip}
[21:04] <pindonga> 2. ln -s /etc/wordpress/config-${local_ip}.php /etc/wordpress/config-${remote_ip}.php
[21:04] <pindonga> 3. apache2ctl graceful
[21:04] <pindonga> how does that sound?
[21:04] <pindonga> that way you still can keep the wordpress stuff in a virtualhost entry
[21:05] <SpamapS> pindonga: thats pretty cool :)
[21:06] <pindonga> SpamapS, should I submit my charm for review somewhere?
[21:06] <pindonga> :)
[21:10] <SpamapS> pindonga: since marcoceppi is totally rewriting the w hole thing.. probably not. But I really do appreciate the effort. :)
[21:10] <pindonga> on the contrary, it was a really useful learning experience
[21:10] <pindonga> thanks for all the help
[23:19] <SpamapS> marcoceppi: hey, while you've been redoing wordpress.. have you come up with any insight on whether the endpoing host would be better off configured on the load balancers or on the app servers?