[00:21] <weblife> Would anyone here be interested in a book about "Engineering Customer Relationship Management Web Applications with Node.js & MongoDB" : https://github.com/webbrandon/simple-secure-auth
[14:21] <lazyPower> Morning Juju o/
[14:22] <rick_h_> lazyPower: woot woot
[14:23] <skay> o/
[16:53] <skay> arg, I don't know why this just started happening. juju bootstrap is failing. it was working earlier today. http://paste.ubuntu.com/9677528/
[16:54] <skay> halp
[16:59] <marcoceppi> skay: you may have some old reminants laying around
[17:00] <marcoceppi> skay: what does `sudo initctl list | grep juju` show?
[17:01] <skay> marcoceppi: juju-agent-sheila-local start/running
[17:01] <marcoceppi> skay: yeah, you've got an unclean destruction of the local provider
[17:01] <skay> marcoceppi: the first time this started happening, I ran http://paste.ubuntu.com/9677575/ in hopes it would clean up everything
[17:01] <marcoceppi> skay: `juju destroy-environment --force local`
[17:02] <marcoceppi> skay: well, that's a start..
[17:02] <marcoceppi> skay: it's missing a few things
[17:02] <marcoceppi> it's a bit overreaching, I should go update that ask ubuntu question
[17:02] <skay> retrying after running destroy-environment --force local
[17:03] <marcoceppi> skay: wait
[17:03] <skay> marcoceppi: same result
[17:03] <skay> marcoceppi: sorry, trigger happy
[17:03] <marcoceppi> run `sudo stop juju-agent-sheila-local` first
[17:03] <marcoceppi> you delete the init file, but never actually stop the process
[17:04] <marcoceppi> you should stop the juju-agent processes first, then run the clean up script
[17:04] <skay> oh cool, I got an interesting error when I tried to stop the process
[17:04] <skay> stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
[17:05] <marcoceppi> skay: right, because you removed the init file :)
[17:05] <mwak_> hi
[17:05] <skay> derp. what do I do now?
[17:06] <marcoceppi> skay: ps -aef | grep mongo
[17:06] <skay> kill that?
[17:06] <marcoceppi> skay: maybe
[17:07] <marcoceppi> depends if it's the right mongo proc
[17:07] <marcoceppi> I think there's something else that runs too
[17:07] <marcoceppi> let me check
[17:07] <skay> there seems to be only one running here
[17:08] <marcoceppi> skay: kill the mongo if it's from /usr/lib/juju
[17:08] <marcoceppi> skay: also, kill any jujud processes running
[17:08] <marcoceppi> of which there may be one
[17:13] <skay> marcoceppi: things are good now
[17:13] <skay> marcoceppi: thanks kindly
[17:14] <marcoceppi> skay: no worries, I'll add this in to the local provider plugin I'm building
[17:14] <skay> marcoceppi: I guess in the script I have, it should go through the list of files in /etc/init/juju-* and sudo service stop them?
[17:15] <marcoceppi> skay: yes, you should basically loop thorugh each of the services listed in `sudo initctl list | grep juju`
[17:16] <skay> marcoceppi: what's going to be in the plugin?
[17:21] <marcoceppi> skay: a whole bunch of stuff, I've outlined here:
[17:21] <marcoceppi> https://github.com/juju-solutions/juju-local
[17:32] <skay> marcoceppi: thanks. btw, I went ahead and started adding the step to put a stop to juju daemons in my script, https://github.com/codersquid/dotfiles/blob/master/bin/juju-cleanup#L16 though I haven't tested it yet. but if you see a problem in that line at a 2 second glance, let me know
[17:33] <marcoceppi> skay: you could add them to the existing juju plugin
[17:33] <marcoceppi> https://github.com/juju/plugins/blob/master/juju-clean
[17:41] <skay> marcoceppi: okay
[18:08] <skay> marcoceppi: I'm not certain the script I'm using does things you'd want in that plugin, but I'll go ahead and submit a PR for comment
[18:35] <skay> marcoceppi: hey, https://github.com/juju/plugins/pull/41
[18:36] <skay> I wish I could remember whoever it was in here who helped with a cleanup script before. what I'm using is based on the answer and on their script
[18:45] <lazyPower> skay: probably mbarnett
[18:45] <lazyPower> er mbruzek
[20:32] <marcoceppi> skay: thanks for the PR, looks good for the most part, left some feedback
[20:54] <designated> what does the little heartbeat icon next to the hacluster charm represent?  does the number indicate the number oc clusters?
[20:54] <designated> s/oc/of
[20:59] <marcoceppi> designated: it indicates the number of services heartbeat is connected to
[20:59] <marcoceppi> since it's a subordinate and can only exist on an existing service
[20:59] <marcoceppi> err
[20:59] <marcoceppi> s/heartbeat/hacluster
[21:18] <designated> marcoceppi: thank you
[21:21] <designated> marcoceppi: is it normal, once clustering completes, for the relation to turn gray and the heartbeat icon to show "1"?
[21:30] <marcoceppi> designated: yes
[21:30] <marcoceppi> subordinate relation lines tend to go grey to stay out of the way of the tree
[21:30] <designated> marcoceppi: thank you, that clears up a little of the confusion
[21:41] <seal_> I have deploy a simple docker charm, which simply installs docker on ubuntu 1404
[21:42] <seal_> when I run juju ssh <service>/0 and
[21:42] <seal_> then run sudo docker run -i -t ubuntu /bin/bash -v
[21:42] <seal_> I get FATA[0000] Cannot connect to the Docker daemon. Is 'docker -d' running on this host?
[21:42] <marcoceppi> seal_: well, is docker -d running on the host?
[21:42] <seal_> tried running sudo docker -d
[21:42] <seal_> yes
[21:42] <seal_> wait
[21:42] <seal_> cheecking
[21:43] <seal_> permission denied and I ran it as root
[21:43] <seal_> also tried running under ubuntu user
[21:43] <seal_> permission denied
[21:45] <marcoceppi> I'm not sure why it'd be doing that, lazyPower ^?
[21:46] <lazyPower> sec - on another problem. be with you shortly
[21:46] <seal_> ok thanks
[21:46]  * lazyPower reads scrollback
[21:47] <lazyPower> seal_: which docker charm did you look at?
[21:47] <lazyPower> seal_: also, that is indeed strange, as sudo - it should have had no problems communicating with it.
[21:48] <seal_> well I could not find any
[21:48] <seal_> so I just wrote a basic charm with a single install hook
[21:48] <seal_> mainly curl -sSL https://get.docker.com/ubuntu/ | sudo sh
[21:49] <seal_> which reported no error even when using juju debug-hooks
[21:49] <lazyPower> seal_: https://github.com/chuckbutler/docker-charm
[21:49] <seal_> ok will try that
[21:49] <lazyPower> seal_: this is our active work target for docker, and when its completed we'll runt he gauntlet of upstream review
[21:50] <lazyPower> it has some preliminary documentatino around cross host networking - but that's going to be the first serious change we make to it, as we're investigating in splitting it out from the charm itself and making it composeable with subordinates
[21:50] <lazyPower> i'm not sure why docker would be doing that to you though - thats a really strange issue to crop up
[21:53] <lazyPower> seal_: feel free to ping with any questions/comments/concerns/issues
[21:53] <seal_> yeah very strange as I have it installed locally and it works
[21:54] <seal_> thanks lazyPower
[21:54] <lazyPower> np
[22:09] <noise][> Hi, I'm trying to troubleshoot an issue where I've got a working relation-changed hook from my website providing charm to haproxy. All is good with the 1st deploy of both services, but when I add a 2nd website unit and it calls relation-set to the haproxy, the haproxy charm's reverseproxy-relation-changed never gets called
[22:09] <lazyPower> noise][: is this being done via add-unit? or are you relating a second charm all together to haproxy?
[22:10] <noise][> add
[22:10] <noise][> lazyPower: add-unit
[22:10] <lazyPower> interesting, it should have called the rp-relation-changed hook to set it as a round-robin target
[22:10] <noise][> y, no sign of it though :(
[22:11] <lazyPower> noise][: can you file a bug against the haproxy charm on this?  https://bugs.launchpad.net/charms/+source/haproxy
[22:12] <noise][> lazyPower: will do. any idea where to start looking to hunt it down? It looks like the haproxy charm just doesn't even get called again
[22:13] <lazyPower> noise][: i would attach to a debug-hooks session on haproxy, run the relationship and try to intercept it and run teh hooks interactively
[22:13] <lazyPower> i suspect whats happening is the hook is getting called but bailing out because its getting a false positive thinking its already configured and doing a no-op
[22:13] <noise][> y, tried that, got no calls
[22:13] <lazyPower> hmmm
[22:13] <noise][> but i'll try again w/a clean start
[22:13] <lazyPower> what version of juju noise][?
[22:14] <noise][> 1.20.10-utopic-amd64
[22:16] <lazyPower> ok thats -stable in utopic, hmm
[22:16] <lazyPower> yeah i cant come up with any reason why it wouldnt' get called
[22:17] <noise][> lazyPower: i should note I'm using the "Relation-Driven Proxying" method, specifying "services=" in the relation-set
[22:17] <noise][> but it works fine for the first website unit, so not sure why it's failing for additional
[22:17] <noise][> anyway, i'll file a bug and continue to hunt
[22:46] <whit> cory_fu, is there a way to beam back changes from a unit w/ dhx?
[22:46]  * whit is trying to figure out sync
[22:46] <cory_fu> whit: -s
[22:46] <whit> so if I have dhx session running without -s cory_fu?
[22:46] <cory_fu> dhx -s unit will automatically do a sync-charm when the session is done
[22:47] <whit> cory_fu, but I have to start it with -s (in the charm dir?)
[22:47] <cory_fu> whit: Well, you could always close the current dhx session and then start a new one with -s
[22:47] <whit> ok... that works
[22:47] <cory_fu> In the charm dir, yes.  You could also just manually run sync-charm
[22:47] <cory_fu> It's pretty straightforward
[22:48] <cory_fu> whit: Basically just: juju sync-charm unit/0
[22:48] <cory_fu> (from within the charm directory)