[00:00] dazz: o/ [00:01] SO! I've been tasked to learn myself some juju. Using a local environment. All was well for the first deploy of wordpress/mysql - awesome. Killed that environment. Tried to write my own charm. Got stuff installing. Killed that environment, now I can't get anything out of a state: pending.... [00:01] where would you suggest I go to find why nothing seems to be happening? [00:02] I'm getting feedback from debug-log - started service unit wordpress/0 - but juju status is still pending? [00:05] dazz: so local provider can be a little quirky atm... we're workign to fix that [00:05] kk. So it's nothing that can be helped at the moment. [00:05] what I'd recommend in the mean time is wiping your lxc cache when you see strange things happening [00:05] hokaydokay [00:06] make sure you start with a 'juju destroy-environment' [00:06] then once everything's down, you can wipe /var/lib/lxc [00:06] nothing seems to be present in /var/lib/lxc... [00:07] hmmm... [00:07] should juju always be run as root in this event? [00:07] maybe it's a permission thing / not getting sudo where required [00:07] well then I'd go through another cycle of 'juju bootstrap' and then deploy something [00:07] should I try as root? [00:07] so juju should be run as a user, but it'll ask for sudo password when it needs it [00:07] better as a user [00:08] yeah cool. Thought as much [00:08] try a 'groups' as the user [00:08] make sure you see libvirtd [00:08] try 'virsh net-list --all' [00:08] should see 'default' and it should be active [00:08] yeap [00:08] confirmed both those [00:08] ok, then bootstrap and deploy something [00:09] during the first deploy, it's gonna sit in 'pending' state for a _long_ time [00:09] (it's installing an operating system template) [00:09] once you've successfully got something like mysql in a 'started' state, then subsequent deploys _should_ go quicker [00:10] roughly how long is a "long" time? [00:10] (it'll cache the machine template in /var/lib/lxc) [00:10] 15-20 minutes? [00:10] yeah... depends on your connection [00:10] excellent. Cheers. [00:10] I know the first time was about 5-10 minutes. [00:10] I'd worry if it takes more than 30mins... typically 10 for me I guess [00:10] cool cool [00:11] Is there a way to get feedback on it's current deployment? [00:11] don't know the best way to see that with the local provider... lemme poke around [00:15] dazz: so there're some lxc tools 'lxc-' and then some logs that go into your 'data-dir' configured in your .juju/environments.yaml [00:19] what is roots passwords for the containers? Default toor for lxc doesn't seem to work. [00:19] does it use an environment setting? [00:19] mysql seems to be running [00:20] I can query it. the mysqld service is not running however. [00:20] dazz: does it show 'started'? if so, you should be able to 'juju ssh mysql/0' [00:21] it'll pick up your primary key [00:21] juju reports that it's waiting for the unit to come up [00:21] but lxc suggests it's already running [00:22] ok, sounds good... the unit will take a bit once the machine is up to install msyql packages and actually run the charm [00:22] hokay-dokay [00:23] so rule number one - don't destroy the environments [00:23] remove the units [00:23] <_< [00:24] you can ssh directly to the machine once it's running 'ssh -lubuntu 192.168.122.xxx' [00:24] rule number one is to wait that first time for a full cache to be built... that happens a lot [00:25] we've got some bugs open to better inform users what the heck is going on [00:25] it's totally confusing and seems like it's jammed [00:25] juju seems really awesome - but it's current documentation is pretty limited. [00:25] yup [00:25] so "long time" and... lol. 10 minutes is long for me XD [00:26] I must have done something the first couple of times when deploying the charms... [00:26] we're working hard to fix that [00:26] no it's okay :) That's what now-informed-users are for. [00:26] ha! [00:27] yeah, the next release is a long-term-support one, so it's gotta be cleaned up by then [00:29] * m_3 bbaib... (coffeeshop -> home) [00:30] cheers sir! [00:30] o/ [00:47] dazz: on the way home I realized I told you the wrong cache to clear... it's /var/cache/lxc and not /var/lib/lxc [00:47] ah ha [00:47] let me try that. [00:47] so if things still aren't good, I'd destroy the environment, wipe that cache, then try again [00:47] cause it's still stalled. [00:47] cheers! [00:47] sorry [00:47] it's all good. [01:01] dazz: there's a bug that will cause it to wait forever on a failed instance... [01:02] dazz: do you see an 'lxc-wait' running? [01:03] not at the moment [01:03] I see lxc-create [01:04] it's probably working better at the moment since I've deleted that cache. [01:04] as in debug-log I see it creating. I haven't been posted "ready" yet. [01:05] was just going to have a shower, come back and see how it's going [01:05] when is the long-term support of juju being released? In 3-6 months or something like that? [01:10] Along with 12.04 [01:10] Though I expect quality will continue to improve well after that. :) [01:11] * SpamapS disappears [01:20] o/ SpamapS [01:21] cheers [02:08] bad file descriptor while attempting to start the containers.... [02:09] ooo [02:09] shit be happening [02:09] lol [03:23] m_3: you about good sir? How does one debug the db-relation-changed process? [03:24] oh.... appears while debugging you hold commands back.... hang 2. Think I'm okay. [03:24] dazz: juju debug-hooks [03:25] dazz: opens a tmux window with the name of the hook you are meant to run [03:25] yes but when you catch lets say, a db-change and a new terminal opens... changes don't happen (like, updating the charm or another db-relation-change) until that window is closed. [03:25] or so it appears. [03:25] right [03:25] thats the entire point. :) [03:25] yeah I missed that <_< [03:26] so I was screaming why -x wasn't working [03:27] when a new tmux window is opened, am I meant to be seeing output of what's going on in my script? [03:29] no you're meant to run your script [03:29] or pretend to run it and do something else.. [03:30] its pausing just before execution, and will respect the return code of your shell (so if you 'exit 1' during an install hook, then your service will be in state: install_error) [03:30] fantastic [03:30] ! [03:30] !!!! [03:30] lol [03:30] awesome - so - I can only do the script - while in that state. [03:30] right, thats the idea [03:30] re: when I was trying ./db-relation-changed I was probably in db-relation-joined [03:30] cheers [03:30] yeap [03:30] getting it [03:31] man I am so documenting all of this [03:32] https://juju.ubuntu.com/docs/write-charm.html#debugging-hooks [03:32] good luck [03:32] * SpamapS goes off to do family stuff [03:33] cheers again sir [05:42] so, is it possible to have two databases on the one mysql unit? [11:24] Morning! === koolhead11 is now known as koolhead17 [11:44] niemeyer: yo! [12:29] hello gustavo [13:04] hi [13:24] nijaba: Hey nijaba, what was the charm that you wrote that uses certificate transfer between charms? [14:24] nijaba: nevermind found it [15:26] when you do a juju charmname set var=something it calls config-changed right? [15:27] lynxman: Correct [15:27] marcoceppi: cool. thanks :) [15:30] <_markh_> I'm new to juju - have a basic question. I understand juju works with LXC ( http://cloud.ubuntu.com/2011/09/juju-in-11-10-beta2-lxc-and-openstack-improvements/ ), but it's not clear to me whether that behaviour made it into oneiric. I'm also having trouble tracking down how I'd go about telling deploy to use LXC rather than Amazon ECS. Is there some fairly complete documentation somewhere? [15:32] _markh_: askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage might help [15:46] <_markh_> Thx [16:54] argh.. digging out this twisted regression is definitely like being a rat in a maze [16:56] hazmat, in twisted itself? [16:57] jimbaker, yeah.. some sort of change to ssl handling had a regression from 11.0 to 11.1 wrt to juju's usage for orchestra provider storage usage [16:57] hazmat, got the scope [16:58] i tried treating the sympton which gets most of the tests working except some which just hang.. just digging through the changelog and while its germaine its not realy clearly what's the operational change.. http://twistedmatrix.com/Releases/Twisted/11.1/NEWS.txt [17:09] chaps when i run juju status -e sample the output seems to be yaml parse-able , however the command also spits out the INFO section so that if i parse the output to python and run print yaml.load(status_command_output) it errors on the last line. Is there a way to output in pure yaml or without the INFO status line? [17:11] secbrid, afaicr it should log on stderr and output on stdout [17:11] if not then it should get a bug report [17:11] ooh riight!! excellent! thanks hazmat will check that now [17:28] indeed, logs are on stderr over here [18:05] nice that works when i separate out the streams. thanks guys [19:51] lp:charm is now lp:charms [19:52] change your push branches accordingly (i.e., lp:~mark-mims/charms/oneiric/mycharm/trunk) [20:10] bzr pull --remember lp:charms/foo works [20:10] you'll need to re-set the push location separately [20:11] is there a way to do that without calling push --remember ? [20:11] reconfigure doesn't seem to have an option [20:11] poolie: ? [20:14] vi .bzr/branch.conf [20:14] or i think maybe bzr configure [20:15] bzr config push_location=lp:.... [20:15] perfect [20:15] oh and that makes extracting the current values cleaner too [20:15] * SpamapS de-awks his script [20:16] does that make it less awk-ward? [20:17] less tawk more rawk [20:19] wow, it's just stand-up night in the channel [21:05] is someone doing something at http://charms.kapilt.com/charms [21:06] i see charms being repeated in the list [21:06] jcastro: sir if you have time check at my merge request :) [21:07] koolhead17: I think jcastro is traveling right now [21:07] m_3: ooh okey. [21:08] koolhead17: also we've made some changes to launchpad that'll cause problems for all charm-related tools [21:08] fixes in progress, but it'll probably leak into the weekend for some tools [21:08] m_3: np. i just saw so was bit confused. [21:09] hazmat: I suspect charms.kapilt.com needs to be redirected at the new lp:charms [21:10] oh looks like it was, but something else caused the dupes [21:12] hmm, haven't addressed it at all [21:12] curious how it handles ;-) [21:12] ah.. dups everything because it keeps historical values [21:13] on the notion that once published ... well its published and possibly installed [21:13] i'll reset it [21:54] hazmat: how long should it take to refresh? [22:01] SpamapS: looks like it's refreshed [22:02] yeah.. should be good now [22:05] ah ok it wasn't at 13:54, done now. :) [22:05] hazmat: thanks! [22:06] doh [22:07] * SpamapS now knows what its like to try and inhale about 0.5oz of sugar free red bull [22:07] swallowing + laughing == near death experience [22:10] SpamapS, a cautionary tale ? ;-) [22:11] The Curse of The Caffeine Addicted Hacker [22:13] hehe