[00:21] 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 === negronjl_afk is now known as negronjl === Guest48642 is now known as rcj === rcj is now known as Guest3092 === ev_ is now known as ev === Odd_Blok1 is now known as Odd_Bloke === liam_ is now known as Guest28200 === coreycb` is now known as coreycb === rbasak_ is now known as rbasak === Guest3092 is now known as rcj [14:21] Morning Juju o/ [14:22] lazyPower: woot woot [14:23] o/ === cmars` is now known as cmars === Guest93916 is now known as balloons === kwmonroe_ is now known as kwmonroe === scuttle` is now known as scuttlemonkey === beuno_ is now known as beuno === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === kadams54 is now known as kadams54-away === urulama is now known as urulama|kids [16:53] 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] halp [16:59] skay: you may have some old reminants laying around [17:00] skay: what does `sudo initctl list | grep juju` show? [17:01] marcoceppi: juju-agent-sheila-local start/running [17:01] skay: yeah, you've got an unclean destruction of the local provider [17:01] marcoceppi: the first time this started happening, I ran http://paste.ubuntu.com/9677575/ in hopes it would clean up everything [17:01] skay: `juju destroy-environment --force local` === kadams54-away is now known as kadams54 [17:02] skay: well, that's a start.. [17:02] skay: it's missing a few things [17:02] it's a bit overreaching, I should go update that ask ubuntu question [17:02] retrying after running destroy-environment --force local [17:03] skay: wait [17:03] marcoceppi: same result [17:03] marcoceppi: sorry, trigger happy [17:03] run `sudo stop juju-agent-sheila-local` first [17:03] you delete the init file, but never actually stop the process [17:04] you should stop the juju-agent processes first, then run the clean up script [17:04] oh cool, I got an interesting error when I tried to stop the process [17:04] stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist [17:05] skay: right, because you removed the init file :) [17:05] hi [17:05] derp. what do I do now? [17:06] skay: ps -aef | grep mongo [17:06] kill that? [17:06] skay: maybe [17:07] depends if it's the right mongo proc [17:07] I think there's something else that runs too [17:07] let me check [17:07] there seems to be only one running here [17:08] skay: kill the mongo if it's from /usr/lib/juju [17:08] skay: also, kill any jujud processes running [17:08] of which there may be one [17:13] marcoceppi: things are good now [17:13] marcoceppi: thanks kindly [17:14] skay: no worries, I'll add this in to the local provider plugin I'm building [17:14] 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] skay: yes, you should basically loop thorugh each of the services listed in `sudo initctl list | grep juju` [17:16] marcoceppi: what's going to be in the plugin? === keithzg_ is now known as keithzg [17:21] skay: a whole bunch of stuff, I've outlined here: [17:21] https://github.com/juju-solutions/juju-local [17:32] 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] skay: you could add them to the existing juju plugin [17:33] https://github.com/juju/plugins/blob/master/juju-clean [17:41] marcoceppi: okay === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [18:08] 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] marcoceppi: hey, https://github.com/juju/plugins/pull/41 [18:36] 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] skay: probably mbarnett [18:45] er mbruzek === kadams54 is now known as kadams54-away === urulama|kids is now known as urulama === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [20:32] skay: thanks for the PR, looks good for the most part, left some feedback [20:54] what does the little heartbeat icon next to the hacluster charm represent? does the number indicate the number oc clusters? [20:54] s/oc/of [20:59] designated: it indicates the number of services heartbeat is connected to [20:59] since it's a subordinate and can only exist on an existing service [20:59] err [20:59] s/heartbeat/hacluster === kadams54 is now known as kadams54-away [21:18] marcoceppi: thank you === kadams54-away is now known as kadams54 [21:21] marcoceppi: is it normal, once clustering completes, for the relation to turn gray and the heartbeat icon to show "1"? [21:30] designated: yes [21:30] subordinate relation lines tend to go grey to stay out of the way of the tree [21:30] marcoceppi: thank you, that clears up a little of the confusion [21:41] I have deploy a simple docker charm, which simply installs docker on ubuntu 1404 [21:42] when I run juju ssh /0 and [21:42] then run sudo docker run -i -t ubuntu /bin/bash -v [21:42] I get FATA[0000] Cannot connect to the Docker daemon. Is 'docker -d' running on this host? [21:42] seal_: well, is docker -d running on the host? [21:42] tried running sudo docker -d [21:42] yes [21:42] wait [21:42] cheecking [21:43] permission denied and I ran it as root [21:43] also tried running under ubuntu user [21:43] permission denied [21:45] I'm not sure why it'd be doing that, lazyPower ^? [21:46] sec - on another problem. be with you shortly [21:46] ok thanks [21:46] * lazyPower reads scrollback [21:47] seal_: which docker charm did you look at? [21:47] seal_: also, that is indeed strange, as sudo - it should have had no problems communicating with it. [21:48] well I could not find any [21:48] so I just wrote a basic charm with a single install hook [21:48] mainly curl -sSL https://get.docker.com/ubuntu/ | sudo sh [21:49] which reported no error even when using juju debug-hooks [21:49] seal_: https://github.com/chuckbutler/docker-charm [21:49] ok will try that [21:49] seal_: this is our active work target for docker, and when its completed we'll runt he gauntlet of upstream review [21:50] 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] i'm not sure why docker would be doing that to you though - thats a really strange issue to crop up [21:53] seal_: feel free to ping with any questions/comments/concerns/issues [21:53] yeah very strange as I have it installed locally and it works [21:54] thanks lazyPower [21:54] np [22:09] 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] noise][: is this being done via add-unit? or are you relating a second charm all together to haproxy? [22:10] add [22:10] lazyPower: add-unit [22:10] interesting, it should have called the rp-relation-changed hook to set it as a round-robin target [22:10] y, no sign of it though :( [22:11] noise][: can you file a bug against the haproxy charm on this? https://bugs.launchpad.net/charms/+source/haproxy === roadmr is now known as roadmr_afk [22:12] 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] 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] 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] y, tried that, got no calls [22:13] hmmm [22:13] but i'll try again w/a clean start [22:13] what version of juju noise][? [22:14] 1.20.10-utopic-amd64 [22:16] ok thats -stable in utopic, hmm [22:16] yeah i cant come up with any reason why it wouldnt' get called [22:17] lazyPower: i should note I'm using the "Relation-Driven Proxying" method, specifying "services=" in the relation-set [22:17] but it works fine for the first website unit, so not sure why it's failing for additional [22:17] anyway, i'll file a bug and continue to hunt === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [22:46] 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] whit: -s [22:46] so if I have dhx session running without -s cory_fu? [22:46] dhx -s unit will automatically do a sync-charm when the session is done [22:47] cory_fu, but I have to start it with -s (in the charm dir?) [22:47] whit: Well, you could always close the current dhx session and then start a new one with -s [22:47] ok... that works [22:47] In the charm dir, yes. You could also just manually run sync-charm [22:47] It's pretty straightforward [22:48] whit: Basically just: juju sync-charm unit/0 [22:48] (from within the charm directory) === kadams54-away is now known as kadams54 === roadmr_afk is now known as roadmr === kadams54 is now known as kadams54-away