[03:59] <_mup_> juju/relation-id r490 committed by jim.baker@canonical.com [03:59] <_mup_> Comments, PEP8, tests [03:59] <_mup_> juju/relation-id r491 committed by jim.baker@canonical.com [03:59] <_mup_> Merged trunk [04:38] <_mup_> juju/subordinate r523 committed by kapil.thangavelu@canonical.com [04:38] <_mup_> revert [06:08] hello [06:09] had a quick question: when I deploy my charm, it works but I always get an "install_error" for the state when I run juju status [06:09] any ideas on what could cause that? [06:10] or what it even means :p === almaisan-away is now known as al-maisan [07:10] ok nevermind, it was something that really was an error :p [08:00] <_mup_> juju/relation-hook-context r492 committed by jim.baker@canonical.com [08:00] <_mup_> Initial commit [09:07] hi [09:20] roubi: if you have a question about juju ask it in the channel [09:22] it's my first time [09:22] on freenode [09:22] so [09:22] am 'i [09:22] in the rong way? === zyga is now known as zyga-afk [09:36] is there any one who have tried juju on an ovh server [10:14] roubi: I have not tried juju at all, but some others have, do you have a question you want answered? [10:16] yes i've [10:17] do you know some one who've tried it using an ovh server [10:46] Hi! [10:46] I have a question about charm development. [10:47] I'm developing a ruby on rails charm, [10:47] the problem is that not all units provide the same relations [10:47] but they all require the same relations with db and so on [10:50] should I spit it to two charms, one for those having http inteface and one for others (workers)? === zyga-afk is now known as zyga === al-maisan is now known as almaisan-away [11:02] arashbm, its possible todo that through a single charm with multiple personalities [11:06] Thanks jamespage. I looked trough the docs at juju.ubuntu.com/docs but I couldn't find any information about it. [11:11] arashbm, its not really a juju feature per-say [11:11] but you can write charms that behave in this way [11:11] * jamespage looks for a good example [11:12] arashbm, what are you writing your hooks in? [11:12] you mean the scripting language? [11:13] I'm using bash for some [11:13] and ruby for the others [11:13] arashbm, OK [11:14] arashbm, does the http interface do anything without the workers? [11:14] i.e. would that be a valid deployment? [11:17] yes, there could be apps consisting only of web-server (simple apps not doing anything in background) [11:17] it could be a worker-only (like spiders and so on) [11:17] and it could be a mixture of both (some web and some workers) [11:34] arashbm, is this a generic ruby on rails charm or is it targetting a specific application? [11:34] It's generic [11:46] hmm... I seem to wait forever sometimes for a new charm to deploy on EC2 [11:46] the EC2 instance itself is up, I can ssh into it [11:46] but the juju machine/unit agents seem to take a long time to deploy [11:47] any idea if this is known or being investigated? [11:54] hmm.. that's interesting, the machine agent process 'python -m juju.agents.machine' seems to be in a loop launching itself on this particular instance [11:54] keeps relaunching every second or so with a new pid [11:56] hey folks, I'll be making a short presentation about juju to a local python user group tonight, any tips? [11:57] bbcmicrocomputer, is that upstart managed? it might have a respawn config [11:57] jamespage: yeah, I think so [11:58] jamespage: it appears the new instance has an old version of juju on it, only 0.5+bzr457-0ubuntu1 and the error of its relaunching is 'machine.py: error: unrecognized arguments: --nodaemon --session-file /var/run/juju/machine-agent.zksession' [11:58] jamespage: any idea how newer version of juju are supposed to propagate to instances? [11:59] jamespage: I assumed the instance was meant to use the same juju repository as what deployed the charm [11:59] bbcmicrocomputer, in your ~/.juju/environments.yaml file you can specify an origin: ppa [11:59] I think by default it will use the version in Ubuntu rather than PPA [11:59] I think* [12:00] jamespage: hmm... how have I got away with not specifying ppa in my environment before then.. I'm sure the other instances have used ppa when I've deployed them from a ppa'ed client [12:05] jamespage: 'If this option is not set, juju will attempt to detect the correct origin based on its run location and the installed juju package.' [12:05] jamespage: it does seem to happen everytime a new juju ppa gets released [12:05] jamespage: so I guess it's something with my version being out of sync when that happens [12:06] jamespage: ok, thanks, I'll specify ppa in the environment === Guest10799 is now known as tobin === tobin is now known as Guest70213 [14:06] Is anyone using local provider or providers other than ec2 for testing? [14:07] arashbm, I use the local provider for most of my dev/test work [14:09] I have problems setting up local provider on 12.04: [14:09] error: Failed to start network default [14:09] error: Cannot open network interface control socket: Operation not permitted [14:10] I tried sudo-ing bootstrap but no hope [14:11] arashbm, can you check a few things for me [14:11] sure! [14:19] arashbm, sorry - trying todo multiple conversations [14:19] as your normal user: [14:19] output from 'groups' [14:19] apt-cache policy juju [14:20] you should not sudo bootstrap - juju will call sudo as required. [14:20] $ groups [14:21] arashbm adm cdrom sudo dip plugdev lpadmin sambashare [14:21] $ apt-cache policy juju [14:21] juju: [14:21] Installed: 0.5+bzr457-0ubuntu1 [14:21] Candidate: 0.5+bzr457-0ubuntu1 [14:21] Version table: [14:21] *** 0.5+bzr457-0ubuntu1 0 [14:21] 500 http://ir.archive.ubuntu.com/ubuntu/ precise/universe i386 Packages [14:21] 100 /var/lib/dpkg/status [14:22] couple of things todo there [14:22] 1) stick your user in the 'libvirtd' group and then do a 'newgrp libvirtd' [14:23] at the moment your user can't see the local virtual network OR create it [14:23] 2) Upgrade to the latest version of juju from the PPA [14:23] 'sudo add-apt-repository ppa:juju/pkgs' [14:23] arashbm, ^^ [14:23] then give it another spin [14:24] Thanks :) === almaisan-away is now known as al-maisan [14:37] negronjl, tomcat charm looks good [14:43] negronjl, a few bits don;t work tho - how do you want feedback? can't help but feel a merge proposal would make this easier [15:28] hi every body [15:29] is there here any one who have tried working with servers from ovh [15:39] m_3, how's your thing coming along? === al-maisan is now known as almaisan-away [15:45] Hi, We are trying to install and test orchestra and juju on two physical machines, we have a problem with juju status. Could you help please [15:47] jamespage: thx for taking the time to check it out. regarding feedback: merge proposal works ... or email or message pigeons too :) [15:48] jcastro: hw issues atm... haven't done any real work yet today :) [15:48] negronjl, MP please [15:49] hi roubi_ so is orchestra by itself able to launch a machine? [15:51] jamespage: let me know the specifics of the things that don't work or, if you have time, you can fix them as well :) [15:52] Hi Hazmat, orchestra is not able to launch a machine [15:52] roubi_, figuring that out, independently of juju is a good first step [15:56] orchestra seems to be installed correctly but can not control power on/off the client === almaisan-away is now known as al-maisan [15:59] hi roubi_: still no luck? [15:59] yes jamespage [16:01] roubi_, have you managed to establish whether the required integrations are supported by your hosting provider (ovh)? [16:03] roubi ^^ [16:05] I don't know how to do it [16:05] I mean this verification [16:05] :/ [16:06] roubi: I remember you have two servers - one running orchestra [16:07] roubi: have you registered the second server in the orchestra/cobbler install on the first one? [16:07] yes it is [16:09] roubi: and if you reboot the second server does it network boot from orchestra and re-install itself? [16:11] when I allocated this 2nd server, it has ubutnu server 11.10 as OS === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [16:13] roubi: yes - but your setup needs to allow orchestra to perform an automated install on this server [16:19] jamespage :do you think that the 2nd server must be with out OS [16:19] ? [16:20] roubi_, whether it has an existing OS is irrelevant - it needs to be able to network boot and install from orchestra [16:23] Yes but Even when I tried this between two pc [16:29] adam_g, btw the openstack charms are looking really nice [16:30] i pulled them out yesterday to show off during a presentation [16:30] hazmat: oh cool :) [16:34] jamespage, i pulled out yours to show some nice bash charms as well [16:34] hazmat, sweet - hope they went down OK [16:35] its quite hard to decide when bash is not enough and you should switch to something like python [16:36] jamespage, they did.. although there was some skepticism over going from dsl back to shell scripts, it was sort of a devops thunderdome deathmatch.. http://www.meetup.com/DevOpsDC/events/46606602/ [16:36] the audience was pretty savy and saw the overall benefits [16:38] hazmat, 'Four frameworks will enter, one framework leaves' - hope we won! [16:39] 'we' as in 'juju' [16:40] jamespage, not quite, but there's a always a round two. [16:40] lol [16:41] who won? [16:45] zirpu, probably chef, their were also some folks from the cfengine company, which was nice.. puppet had some usage but not as much love. === al-maisan is now known as almaisan-away [16:53] hazmat: m_3 might want your slides as he's been placed in a thunderdome for the DevOpsDays event in Austin :P [16:54] robbiew, i put mine together under the gun mostly from your lisa slides and some of SpamapS , ie. simple rehash, didn't really have time for anything new.. but i could definitely share some of my cage technique ;-) [16:55] "cage technique"...lol, nice [16:58] hazmat robbiew: definitely wanna talk beforehand [16:58] it'll be fun [16:58] m_3: I'll have shirts to win over folks ;) [16:58] short intro though... so gotta pick a very few apropos slides [16:58] robbiew: awesome [16:58] puppetlabs is sponsoring a damn happy hour :/ [16:58] yikes [16:58] goes along with the puppet shirt tho [16:59] * robbiew has the canonical credit card...just sayin [16:59] :) [16:59] tbh, we'd probably do better by staying above the fray...maybe even showcase a charm with puppet (they're in main) [17:00] ...chef isn't in Ubuntu 12.04 [17:00] at the request of OpsCode (for those reading this) [17:00] right... planning on a charm pulling chef from gems though [17:01] I'm thinking of framing it as we're staying _below_ the fray... underlying coordination/eventing framework... etc etc [17:24] m_3: well, "above" would support our devopsolution meme...but whatever :P [17:25] robbiew: yeah, true [17:32] so what's the best way to communicate between python and Go nowadays? net/jsonrpc ? [17:32] sorry, wrong chan === Guest70213 is now known as tobin [17:54] <_mup_> juju/relation-hook-context r493 committed by jim.baker@canonical.com [17:54] <_mup_> Fix failing tests === koolhead17|away is now known as koolhead17 [19:01] question: does juju talk to maas or cobbler? [19:23] could someone help me with my local charms, i have setup an ubuntu server with lxc and juju. I can deploy charms from the examples installed on the system, but not from my downloaded charms folder. I'm trying to # juju deploy --repository charms/ local:mysql [19:23] but this responds in [19:23] 2012-03-21 19:21:30,033 INFO Searching for charm [19:23] Invalid value for force_https: False [19:23] 2012-03-21 19:21:30,278 ERROR Invalid value for force_https: False [19:23] jaaap: this is due to a bug in older charms [19:24] *looks for bugs* [19:24] i just tried mysql, wordpress and munin all fails, loaded my charms with # charm getall ~/charms/oneiric [19:30] it's very weird, i just copied the munin charm from ~/charms/oneiric/munin into /usr/share/doc/juju/examples/oneiric and did # juju deploy --repository /usr/share/doc/juju/examples local:munin which works, but not with # juju deploy --repository charms/ local:munin [19:34] jaaap: right, juju checks all charms in the repository. If one has an error then juju will fail [19:34] it's been fixed in the latest ppa version [19:37] marcoceppi: i'm running Version: 0.5+bzr486-1juju3~oneiric1, did # sudo add-apt-repository ppa:juju/pkgs ; sudo apt-get update && sudo apt-get install juju charm-tools apt-cacher-ng zookeeper libvirt-bin lxc [19:37] i'm not sure if there is another way to get the latest juju [19:37] that's the latest, I believe. One second [19:43] SpamapS: doing some mysql-mmm installs today I got some ideas on creating a mysq-mmm charm [19:44] <_mup_> juju/relation-hook-context r494 committed by jim.baker@canonical.com [19:44] <_mup_> Flush any additional relation hook contexts that are read, then possibly written [19:44] <_mup_> juju/relation-id r492 committed by jim.baker@canonical.com [19:44] <_mup_> Remove unused function [19:45] SpamapS: thinking along the lines of having relation go mysql-mmm-service << mysql-server [19:45] <_mup_> juju/relation-hook-context r495 committed by jim.baker@canonical.com [19:45] <_mup_> Merged upstream [19:49] ninjix: sweet, I've heard good things about mmm [22:21] anyone know what might be causing ERROR invalid value force_https: False when I juju deploy mysql? [22:23] krondor: yes, check the config.yaml file of all the charms in your repo [22:24] krondor: strict-typing just landed for this file... if it uses a string field like "False" you need to change it to boolean _and_ False (no quotes) [22:24] m_3: thanks found it, roundcube apparently. [22:25] there're a host of them... I'd recommend only keeping the charms you need in your repo atm [22:25] at least until we have this problem fixed [22:26] m_3: no worries, moved to just what I need and all is good for testing again. [22:27] krondor: awesome [23:05] m_3, are the inprogress charms also mirrored on github? [23:13] jcastro: nope [23:13] only charms that have lp:charms aliases [23:13] i.e., for oneiric [23:14] * jcastro nods [23:14] is it hard to include the others? [23:14] just thinking outloud [23:15] if people want to github prior to submitting is what I was thinking [23:15] jcastro: no, it wouldn't be hard... just was eliminating noise [23:15] we'd have to figure out a good naming scheme [23:15] I'll test out some stuff [23:16] ok [23:20] jcastro: someone could fork one of the official repos into their own acct, then submit a pull request onto the main branches [23:21] alternatively, they could start a charm on a repo in their acct [23:21] then let us know it's ready for review [23:22] it'd still be manual for now, but we could automate stuff if we get lots of interest in that channel of submission [23:23] * jcastro nods