#juju 2012-01-01 <nijaba> Happy new year charmers #juju 2012-01-02 <nijaba> Good morning * SpamapS shakes the rust off his IRC client <nijaba> Hey SpamapS, Happy new year <SpamapS> likewise * SpamapS has not even been reading email.. slogging through it now <nijaba> SpamapS: no worries. #juju 2012-01-03 <rog> mornin' all, and happy new year! <mpl> rog: same to you Roger :) <rog> mpl: hiya <nijaba> HNY rog & all <koolhead11> hello nijaba <nijaba> Hey koolhead11! hope you had a nice break <koolhead11> yes sir. :) <TheMue> A stormy HNY from Germany too. ;) I hope the trees in front of our house will survive those gusts. <koolhead11> TheMue: <koolhead11> :P <TheMue> koolhead11: Hey :S <TheMue> koolhead11: But so far everything is ok. ;) <koolhead17> TheMue: the sounds good. <TheMue> koolhead17: yep <freeflying> wondering how can I get juju + lxc works on a laptop, anyone has any clues? <therve> freeflying, https://juju.ubuntu.com/CharmSchool should have the necessary bits <freeflying> therve: I did following that pages tells, but no lucky at all on oneiric, bootstrap is fine, afterwards, all machines will be just pending there <therve> freeflying, did you reboot in the process? <freeflying> therve: after libvit-bin installed, yes <therve> I don't know then <therve> it used to work at least <jcastro> woo, back to the grind folks! <koolhead17> hey jcastro :) <m_3> morning gang <marcoceppi> Morning <freeflying> still have problem with juju + lxc on laptop, container started successfully after deploy, but juju status shows them in pending, can ssh into the container, anyone has ideas on this? <koolhead17> freeflying: it takes sometime i suppose :) <freeflying> koolhead17: usually how long does it take? :) <koolhead17> freeflying: pastebin juju -v status <koolhead17> freeflying: on machine like mine with 2 gigs RAM long enough :P <freeflying> koolhead17: http://paste.ubuntu.com/791723/ <freeflying> koolhead17: I'm going to leave my laptop running alone there :), and get into bed, hope everthing will be going as expected in 8 hrs :P <koolhead17> freeflying: another thing you can do is check log inside your data-dir <koolhead17> freeflying: hehehe. i guess it will take less time :P <koolhead17> freeflying: if your interested in debugging i can show u the way :P <freeflying> koolhead17: I'd love to, since I'm going to give a talk on juju in couple of days at a confenrence :P <koolhead17> jcastro: wont it be good idea to modify the documentation and come up with some starred kind of thing saying about memory and time taken for juju to bring up instance? <jcastro> yeah, I need to talk to hazmat about docs <koolhead17> freeflying: awesome, well in that there are other folks here who can help you as they are more knowledgeable than me :P <jcastro> freeflying: is this the first time you're running it? <jcastro> the first time takes a while <jcastro> after that when everything is cached it's like a few seconds for me <freeflying> jcastro: actually I tried before, but not sure if I gave it enough time before I destroy them :) <koolhead17> freeflying: one simple suggestion <koolhead17> try installing only mysql charm <koolhead17> and unless/until it comes in running mode dont deploy wordpress charm <koolhead17> i remember facing same in first time :P <freeflying> koolhead17: ok, just destroyed previous environment, and re-deploy mysql only <koolhead17> freeflying: cool <freeflying> koolhead17: how can I check whether the charm has been deployed into the container? <koolhead17> freeflying: juju -v status will give you information about the container <id> <koolhead17> in the environments.yaml you must have provided juju data-dir <koolhead17> go there <koolhead17> you will find something like <username>-sample <koolhead17> inside there u will have a directory units <koolhead17> it has all the meat u require :P <hazmat> jcastro, pong <freeflying> koolhead17: ssh into the container just deployed(not with juju ssh), and there is nothing running inside the container shows mysql will be deployed <koolhead17> freeflying: is mysql charm finally running"? <freeflying> koolhead17: no, juju status told its still in pending <hazmat> freeflying, do you see the containers twice in the output of lxc-ls ? <hazmat> lxc-ls shows all extant containers, and does a separate line for running containers (so its listed twice if running) <freeflying> koolhead17: yes <freeflying> hazmat: yes <freeflying> freeflying@x200:~$ sudo lxc-ls <freeflying> freeflying-lxc-0-template freeflying-lxc-mysql-0 <freeflying> freeflying-lxc-mysql-0 <m_3> marcoceppi: do you have a gist for using the ch downloader/verifier? <koolhead17> jcastro: around <marcoceppi> m_3: Not really, I could make one if you like <m_3> marcoceppi: nah, just wondering if you had one in place already... thanks tho! <koolhead17> freeflying: did you install Juju from PPA? <freeflying> koolhead17: yes <koolhead17> freeflying: juju -v status <koolhead17> if any luck <koolhead17> :P * koolhead17 being optimist <hazmat> freeflying, inside of $data-dir/units/mysql-0 there should be logs from the unit agent that might be helpful here <hazmat> also worthwhile to verify the unit agent is running via ps aux | grep juju <hazmat> should show the machine agent for local host and the unit agent for the container <freeflying> hazmat: only the one for on host is running <hazmat> freeflying, hmm.. could you pastebin the master-customize.log in $data-dir <hazmat> freeflying, typically if the unit agent doesn't come up its a problem getting the initial container setup correctly <koolhead17> nijaba: i have been able to get few off the issues in owncloud charm as you pointed getting fixed :P <nijaba> koolhead17: sounds great! Tell me when you need another review <koolhead17> nijaba: by this week end sir :) <nijaba> koolhead17: looking forward to it <koolhead17> thanks <freeflying> hazmat: http://paste.ubuntu.com/791761/ <koolhead17> hazmat: any idea when are we getting done with the juju bug so it works with eucalyptus? <hazmat> freeflying, it looks like the install failed into the template container <hazmat> Hash Sum mismatch and failed to fetch some archives <jcastro> oh neat, cacti over the break <jcastro> marcoceppi: thanks for the review <marcoceppi> jcastro: Yeah, still writing the full review, there's a lot left do to for that one * jcastro nods <jcastro> I'm just happy to see a guy show up! <SpamapS> koolhead17: I'm not sure there is a bug in the latest Ubuntu+juju <SpamapS> koolhead17: IIRC the problem was that txaws was too old on lucid <koolhead17> SpamapS: so we need to try juju+eucalyptus+oneiric to get that particular doubt/issue whatever fixed <SpamapS> koolhead17: eucalyptus can be on any platform, but juju should be run on oneiric talking to the eucalyptus box <SpamapS> We should probably try to get a euca and an openstack setup and run our ftests against it <koolhead17> SpamapS: that would be awesome. <koolhead17> SpamapS: also as you mentioned i need to get an oneirc instance running via eucalyptus and get juju configured on that.? am i correct sir ? <SpamapS> koolhead17: um, no. ;) <SpamapS> koolhead17: you just need oneiric *somewhere* that can communicate with eucalyptus <SpamapS> koolhead17: it could be an instance, or a VM on a laptop, or something else. * koolhead17 scratches his head 5 times <nijaba> SpamapS: do you have time to work on my buildd issue? <SpamapS> nijaba: sure, remind me where to start. <nijaba> I'll resend my last email which is a nice summary <nijaba> SpamapS: see your inbox * SpamapS recoils in horror upon seeing his swollen bloated spam infested inbox <nijaba> SpamapS: I can pastbin my email if you prefer :) <SpamapS> nijaba: regarding your question, I think I should change the Makefile to only run tests on 'make check' instead of also on 'make install'. This makes sense, make install is run with fakeroot, while make check is not. * SpamapS does that * nijaba does happy dance <SpamapS> nijaba: ok, pushed <SpamapS> nijaba: you should be able to kick off the auto-build from code.launchpad.net/charm-tools <nijaba> SpamapS: I am, but I need to reauest a merge of take-trois first <nijaba> SpamapS: merge review requested <SpamapS> hm looks good, testing now.. but I just noticed a bug in my code.. <SpamapS> using exit 0 where the test should really return 0 or something. Hrm. <SpamapS> may have to refactor the tests a bit to stick them each in their own function so they can skip themselves. <nijaba> ah, true... <SpamapS> Fine for now though <SpamapS> tests/helpers/helpers.sh: 39: /home/clint/src/charm/buildd-fixes-take-trois/tests/helpers/test_peer.sh: cannot create /tmp/tmp-juju-log: Permission denied <SpamapS> looks like that needs to be a mktemp -d <SpamapS> tests/helpers/helpers.sh: 190: /home/clint/src/charm/buildd-fixes-take-trois/tests/helpers/test_peer.sh: cannot create /tmp/result: Permission denied <nijaba> SpamapS: it's a file actually, and I wanted to keep the same name over multiple runs <SpamapS> nijaba: then you'll need to put the username in it <nijaba> SpamapS: ?? <SpamapS> I can't run "as a test user" <SpamapS> because I ran as my regular user already <nijaba> SpamapS: ah, right! will fix <SpamapS> should probably clean those files up on success <SpamapS> /tmp/result is also a bad file name. ;) <nijaba> SpamapS: I truncate on each run <SpamapS> yeah but you can't just use /tmp/result .. mktemp <nijaba> SpamapS: you are right <SpamapS> (and then make sure that file is cleaned up in your trap if it exists) <SpamapS> Otherwise it works fine once I rm those two files from my main user <nijaba> SpamapS: ok, changes pushed <jcastro> m_3: I'm going to give zenoss one day or so to catch up with the new years and then I'm going to ask for a call this week or next <SpamapS> nijaba: you can't just rm tempfiles after you're done with them. You have to do it in the exit trap. <SpamapS> nijaba: otherwise an error leaves files sitting in /tmp <SpamapS> not the end of the world <SpamapS> but bad form. ;) <SpamapS> actually I think you're ok here.. <SpamapS> there's no possibility for error. <SpamapS> unless echo fails. ;) <SpamapS> nijaba: note that you don't actually need that result file.. you could just | grep <SpamapS> 2>&1 | grep anyway <nijaba> SpamapS: noted <nijaba> thanks <m_3> jcastro: sounds good on zenoss... anytime's good for me <m_3> jcastro: maybe before budapest tho? <jcastro> yeah so, this week <m_3> jcastro: should I talk to the guys I know there beforehand? <jcastro> oh I didn't know you knew people * m_3 gets around <jcastro> m_3: sigh, I failed to include you on CC <jcastro> fwding the info now <m_3> (beach boys stuck in my head now) <mchenetz> Good afternoon and Happy Holidays! <jcastro> hey mchenetz! <jcastro> how were your holidays? <mchenetz> jcastro: they were good and yours? <jcastro> good good! <mchenetz> I was busy during the holidaysâ¦ However, i am getting back to the OSX implementation now <jcastro> SpamapS: Got time soonish? <SpamapS> jcastro: now's good <jcastro> SpamapS: I just sent you a mail with the text. <jcastro> G+? <SpamapS> sure let me grab my G+ machine <SpamapS> jcastro: invite when ready <SpamapS> I hate technology <jcastro> SpamapS: I can hear the feedback when I yell <jcastro> so I think it's getting to your laptop <jcastro> phone? <jcastro> or irc is fine <EvilBill> Wow, back here from the holidays. <EvilBill> Big fun. <SpamapS> EvilBill: w/b <freeflying> /win 34 #juju 2012-01-04 <SpamapS> hrm.. I think we need a charm helper for dbconfig-common <SpamapS> marcoceppi: looks like you had to jump through some hoops to turn it off for phpmyadmin <marcoceppi> SpamapS: It wasn't pleasent <SpamapS> the whole idea of dbconfig-common actually isn't very pleasant <SpamapS> its a constant source of bug reports <marcoceppi> Trouble is, it'll likely be different for each service <marcoceppi> SpamapS: that's why I wanted to use upstream install for the charm :) <marcoceppi> The solution was easy enough after playing around for a while <SpamapS> So I'd like to reduce it down to 'ch_dbconfig_install packagename' and then in the hooks 'ch_dbconfig_config answer1=foo answer2=bar' <marcoceppi> What would ch_dbconfig_install do? <SpamapS> marcoceppi: install it but leave it unconfigured <marcoceppi> How would that be an advantage over this? https://gist.github.com/1557729 <SpamapS> marcoceppi: taking advantage of the packager's work to configure for the database seems useful. <SpamapS> marcoceppi: I suppose another option would be to ch_dbconfig_disable packagename .. and after that it would be up to the user. <SpamapS> marcoceppi: one can always assume $packagename/dbconfig-(install|upgrade|reinstall) for disabling * SpamapS is still resisting the urge to use git. <marcoceppi> I like the idea of having it simplified down to "auto-filling" based on package name, so ch_dbconfig_config <package> selection1=value selection2=value which would just translate it out <marcoceppi> I would have like to maybe used dbconfig and set db-host, db-user, db-pass when db-admin-relation-changed was fired, but it just seemed too... flaky to me <marcoceppi> Not very idempotent <marcoceppi> at least, from what I understand <SpamapS> postinsts and configs are idempotent by nature <SpamapS> so you would just re-run debconf-set-selections, and then 'dpkg --reconfigure foo' <SpamapS> err <SpamapS> might be --configure foo * SpamapS is still re-learning his job after a week detached from the internets.. :-P <marcoceppi> :) <smoser> hey. <smoser> wondering if someone could point me at what would be the most current instructions (or where i should start) for using the orchestra backedn <koolhead11> hi all <_mup_> juju/ssh-known_hosts r460 committed by acolon@example.com <_mup_> orchestra knows the dns_name; no need to look it up (and change corresponding mocks) <SpamapS> smoser: around now.. I think there are some instructions on wiki.ubuntu.com .. but I forget. They *should* be on https://juju.ubuntu.com/docs <_mup_> juju/ssh-known_hosts r461 committed by acolon@example.com <_mup_> Fixed bad mock setup <_mup_> juju/ssh-known_hosts r462 committed by acolon@example.com <_mup_> Properly mock saving launch state <hazmat> yikes the review queue is huge <SpamapS> hazmat: https://code.launchpad.net/~daker/juju/small-fix/+merge/68038 , should we mark that as WIP ? <hazmat> SpamapS, i suppose, i ended up contributing the unit test there, but lacking the agreement its not clear that it can go in, its a trivial though <hazmat> yeah <hazmat> wip <SpamapS> hazmat: I have a better idea for how to automate destroy-environment btw <SpamapS> hazmat: -y is scary, like rm -rf. What about requiring UUID of some kind? <hazmat> SpamapS, uuid? <hazmat> like pass in a secret on the cli for confirmation <hazmat> seems odd, the unix'e way is to just pass a flag <SpamapS> hazmat: not a secret.. <SpamapS> hazmat: the environment should have a UUID that is generated at bootstrap, and shown in status. Then you have to specify *that* UUID to destroy-environment <SpamapS> hazmat: that way you don't accidentally destroy an environment you didn't mean to destroy. <SpamapS> hazmat: if no UUID is expressed, then the y/n question is still asked (and if there's no TTY, then flat out refusal happens) <SpamapS> hazmat: I'm still worried about automated oopses <hazmat> SpamapS, hmm.. as a check it seems sound, as for usage, it seems over wrought. i'd rather just spec the flag. <hazmat> SpamapS, at the end of the day humans are always a weak link ;-) <SpamapS> hazmat: one other thought is to require the environment name be specified explicitly (ignore the default) <SpamapS> this is not humans, this is code <SpamapS> hazmat: I'm just concerned about automated scripts that have no idea whats in ~/.juju/environments.yaml and get run accidentally. <SpamapS> hazmat: effectively we are encouraging people to write scripts that do 'rm -rf .' <hazmat> SpamapS, good point <hazmat> but scripting environment destruction is what their trying to do <hazmat> we can either make that command non orthogonal wrt to environment spec, come up with arbitrary uuid that's not used anywhere else, or just do the common thing which is request a flag for specifying force/assume yes <SpamapS> yeah, we should recommend that -e xxxxx always be used with destroy-environment <jimbaker> reminds me of gmail goggles <SpamapS> hazmat: training wheels off.. I think thats the way to go * SpamapS wishes his man page had been accepted so he could update it.. ;) <hazmat> SpamapS, that seems like a reasonable safety belt if using -f <hazmat> SpamapS, is it in the review queue anymore? <SpamapS> no <SpamapS> it was rejected since we should, in theory, be able to coerce argparse into generating the man page <jimbaker> that was back from dublin days <hazmat> ah <SpamapS> I sat down to do that a few weeks ago.. <SpamapS> and argparse made me throw up in my mouth a little <hazmat> i think we've given up on that <hazmat> SpamapS, yeah.. its not pretty to extend <SpamapS> I think actually what we *can* do is parse out the --help .. as its structured enough to be machine parsable <SpamapS> sometimes the way python classes are written makes me really really confused <SpamapS> coming from C++ -> java -> perl -> php .. extending and overriding is so much more natural in most cases. <SpamapS> python classes seem to just do weird stuff <jimbaker> SpamapS, i don't think you can use argparse as an exemplar. probably too much attempt in that codebase to support the old optparse approach however <SpamapS> $ juju deploy --help <SpamapS> error: Environments configuration error: /home/clint/.juju/environments.yaml: environments.sample.region: expected 'us-east-1', got 'sa-east-1' <SpamapS> Heh.. thats annoying. <SpamapS> --help shouldn't care. :) <_mup_> juju/ssh-known_hosts r463 committed by acolon@example.com <_mup_> Do not assume current test code is correct ;) <SpamapS> hazmat: https://code.launchpad.net/~nijaba/juju/autocomplete/+merge/86159 .. do you think that counts as a trivial? * hazmat peeks <hazmat> SpamapS, indeed * nijaba frowns to see his first juju core contrib counted as trivial :D <SpamapS> we need to use a different word <SpamapS> how about 'elegant' ? ;) <nijaba> hehe MUCH better <SpamapS> hazmat: ok I'll just commit that <_mup_> juju/ssh-known_hosts r464 committed by acolon@example.com <_mup_> Fixed remaining orchestra provider test * SpamapS notices a second trivial change that is needed... remove --placement <SpamapS> nijaba: https://code.launchpad.net/~charmers/+archive/charm-helpers/+recipebuild/149052 <SpamapS> nijaba: cross your fingers! <jcastro> m_3: so hey, crazy jorge idea validation time <jcastro> I was reading on planet devops about this: http://newrelic.com/ <jcastro> it's saas but it has agents and whatnot <jcastro> https://github.com/newrelic/rpm <SpamapS> jcastro: a friend of mine has been using that and said its really nice. <jcastro> right, ditto <_mup_> juju/ssh-known_hosts r465 committed by acolon@example.com <_mup_> Removed debugging <jcastro> so my question is, is this a place where juju can help? <jcastro> juju add-relation newrelic myservice does the magic and then you just go to the website and you have it all set up kind of thing. <SpamapS> jcastro: feels a lot like something you would subordinate into your machines <jcastro> yeah so this is why I asked <jcastro> SpamapS: http://www.jedi.be/blog/2012/01/04/monitoring-wonderland-moving-up-the-stack-application-user-metrics/ <jcastro> then I started wondering how many of these are open and could be juju'ed <jcastro> or if it's lower in the stack <SpamapS> "Part of their secret of success is the easy at how developers can get metrics from their application by adding a few files, and a token." <SpamapS> bad translation? <SpamapS> jcastro: we'd have to look into what they do, but if they are passive and just observe existing output of ruby/php/etc. apps, then it might be an easy win once we have subordinate services <jcastro> statsd looks cool <SpamapS> hazmat: where are we with lp:juju/docs ? still generating from trunk or is it fully split now? <SpamapS> jcastro: didn't westby tackle that or something? <jcastro> dunno, but it must be awesome, it's node.js <jcastro> :) <SpamapS> sooooo hot <avoine> I'm working on the a charm and I'm not sure how much configuration I should add in the config.yaml. Is more is better then less? <avoine> for a public charm <SpamapS> avoine: depends entirely on the service. <jcastro> what service? It would be nice to know so I can track it! <avoine> it's already there it's python-moinmoin <SpamapS> avoine: but for the most part, I say if it *is* tweakable, put it in config.yaml. <avoine> ok <SpamapS> avoine: if there are like, 100's of variables, then it may be best to have a single config option.. "override values" which users can just set after reading moinmoin's docs. But if there are only like, 20 or so, its nice to have them spelled out in config.yaml. <jcastro> oh rock and roll, that would be a nice one <avoine> SpamapS: "override values" is a good idea <avoine> I'll do that <jcastro> good one, captured! https://juju.ubuntu.com/CharmGuide <SpamapS> jcastro: ^5 <jcastro> marcoceppi: I am pretty sure you have like, dozens of opinionated things you could add there, heh <marcoceppi> jcastro: heh, yeah :) <SpamapS> please keep it to your charm opinions.. "And whats with Burritos? They're not little burros, so why burritos?!" <marcoceppi> A charm review check list could be nice <m_3> jcastro: newrelic is ok... I used it for a couple of clients in the past. there're a few different tools in that space <m_3> jcastro: have to think about how juju could best help... the monitoring setup is pretty lightweight (it'd be a trivial charm) but the app integration is where the meat really is <m_3> don't even know if they have an option to set up your own monitoring service with it <m_3> i.e., your own mother ship <jcastro> m_3: yeah as I peruse some of these I am seeing some that could be awesome, and some not. <jcastro> I just hadn't thought of measuring tools in such a detailed way, now I am seeing all these tools and wondering. <jcastro> also, the more I learn about things like this, the more I wish I could go back in time and fire myself from my old jobs for being dumb. <m_3> seems like sensu would be a better way to spin up your own... newrelic does the full saas package for you <m_3> ha! <m_3> yeah, hindsight huh <hazmat> SpamapS, not sure its being generated at all atm <SpamapS> hazmat: oi. Ok, well there are a few docs/* things waiting to be merged.. we should make it clear where they go and get them merged and out of the queue. <hazmat> SpamapS, i only see one from mbp? * hazmat looks around <SpamapS> hazmat: there's one from Ahmed that I put back to WIP but will be simple to correct, and one from rog as well <SpamapS> anyway, I have to run, bbiab #juju 2012-01-05 <SpamapS> hazmat: https://launchpadlibrarian.net/89092620/buildlog_ubuntu-precise-i386.juju_0.5%2Bbzr440-1juju2~precise1_FAILEDTOBUILD.txt.gz * SpamapS sometimes wonders if the buildds are just too hostile to run juju's test suite inside of * SpamapS retries it <jelmer> SpamapS: urgh, spurious failures suck <jelmer> SpamapS: that last failure looks odd - "dictionary changed size during iteration" while you're already taking a list() of the dictionary items to iterate over <SpamapS> jelmer: I'd pinpoint it to a precise library problem if I could get the automatic builds to work on oneiric/natty/maverick/lucid ... but the java build-dep causes us to hit the 1G limit about 90% of the time. <jelmer> ah, bug 693524 ? <_mup_> Bug #693524: Daily builds of Java packages fail: "Could not reserve enough space for object heap" <recipe> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/693524 > <SpamapS> jelmer: indeed <SpamapS> jelmer: most frustrating about that is that because it is seemingly random.. the PPA has 4 different versions of juju in it. <_mup_> juju/ssh-known_hosts r467 committed by acolon@example.com <_mup_> Test concurrent update of known_hosts file <_mup_> juju/ssh-known_hosts r468 committed by acolon@example.com <_mup_> Cleanup of concurrent process test <wrtp> mornin' all <koolhead17> hi all <koolhead17> jcastro: ping <nijaba> koolhead17: would be surprised if jcastro wa already awake, he is east coast based <koolhead17> nijaba: sorry, i always get confused with the timezone slaughter :( <TheMue> koolhead17: My little friend here is http://www.worldtimebuddy.com/. Here I've stored the locations of the whole team. ;) <koolhead17> TheMue: cool * hazmat yawns <lynxman> hazmat: whenever you got your coffee with you, what was the file again where the juju client writes its zookeeper node address? <hazmat> lynxman, its the key 'provider-state' in the provider storage <lynxman> hazmat: hmm okay, any recommendation in how to alter it through the command line? :) <hazmat> lynxman, um.. there isn't one, what's the problem your trying to solve? <lynxman> hazmat: just continuing on what we talked, trying to instantiate a machine, setup stunnel and a juju client through cloud-init and then connect back to zookeeper through stunnel <hazmat> lynxman, ic, so in this case you just want to get the zk addr? <lynxman> hazmat: exactly, just tell to the new instantiated machine "your zookeper is at localhost:37173" for example <lynxman> hazmat: which will be the endpoint of the stunnel connection <hazmat> lynxman, it really depends on the provider, typically a machine is setup to launch the agents with zk address.. ie the cli for the agent has JUJU_ZOOKEEPERS environment var set to the address, it doesn't poke directly at the provider storage <lynxman> hazmat: aaah so it'd be as easy as making sure the variable is setup in the permanent environment of the machine then? <hazmat> lynxman, for testing sure <lynxman> hazmat: k, the var is a dictionary? "+1-473-444-0812:1234,+1-473-444-0812:1234" and such? <hazmat> ie. you could just launch the agent process and hand it another address, the place where we give the machine agent process its address is in the providers/common/launch.py via cloud-init.. it (the cli or provisioning agent) will poke at the provider-storage to figure out the extant zk servers to setup in cloud-init <hazmat> lynxman, its a comma separate string, of the form you just posted <lynxman> hazmat: excellent, many thanks :) <hazmat> lynxman, np <wrtp> hazmat: is there a team meeting today? <hazmat> wrtp, good question, we can do one, but i'm not sure we have quorum <hazmat> it looks like gustavo, william and myself are on vacation.. i'm game though <wrtp> hazmat: ah, i wondered who was still on holiday. <TheMue> wrtp: I've got to miss the meeting, we've got an important parents' evening here. Our younger daughter has a class trip the next week (no, not to Budapest *lol*). <wrtp> TheMue: that's fine - i'd assumed it's not happening anyway * TheMue too <hazmat> wrtp, yeah... let's skip it.. we'll all be around next week in person <wrtp> hazmat: k * hazmat takes dog to vet <koolhead17> jcastro: around? <jimbaker> hazmat, sounds good <jcastro> koolhead17: yo <koolhead17> jcastro: am still waiting for mail sir!! :P <jcastro> sorry I've been slammed <jcastro> I'll do it now <koolhead17> jcastro: awesome. <koolhead17> jcastro: got it!! :P * SpamapS works through the juju MIR <SpamapS> hazmat: have you tried running the txzookeeper test suite? I get quite a few failures on it right now <hazmat> SpamapS, checking <hazmat> SpamapS, the txzk test suite is a little odd, it requires a running zookeeperd it doesn't manage it the same way that juju does <SpamapS> hazmat: working on running test suites on all package builds.. but 'trial txzookeeper' is looking pretty gruesome on the precise version <SpamapS> oh <hazmat> SpamapS, basically apt-get install zookeeperd <SpamapS> so just install zookeeperd package an it will start working? <hazmat> yup <SpamapS> ok I can do that. <SpamapS> still getting tons of fail <SpamapS> ew and it creates a statically named temp dir <SpamapS> hazmat: ugh, there's a bug in zookeeper where it listens on 33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab:2181 and not +1-473-444-0812:2181 <hazmat> SpamapS, it doesn't listen on all ifaces? <hazmat> SpamapS, i put in a bug to switch over the txzk tests to manage their own server <_mup_> juju/ssh-known_hosts r469 committed by acolon@example.com <_mup_> Test key update in known_hosts <SpamapS> hazmat: no it doesn't.. bug 888643 .. <_mup_> Bug #888643: Zookeeper listen only to IPv6 interface <zookeeper (Ubuntu):Confirmed> < https://launchpad.net/bugs/888643 > <SpamapS> hazmat: or rather, it does, but only all ipv6 interfaces <SpamapS> there seem to be other problems <SpamapS> its creating /var/lib/zookeeper wrong as well <_mup_> juju/ssh-known_hosts r470 committed by acolon@example.com <_mup_> Test key update in known_hosts <SpamapS> adduser: Warning: The home directory `/var/lib/zookeeper' does not belong to the user you are currently creating. <SpamapS> ahh <SpamapS> they've listed the dir in the package * SpamapS fixes <jimbaker> oops, way too quick on choosing which command to repeat ;) <SpamapS> jimbaker: restoring from backups is just an opportunity to go get coffee. :) <jimbaker> SpamapS, ;) <jimbaker> running our unit tests fully is a perfect amount of time to make some tea, for sure <SpamapS> thats true <_mup_> juju/ssh-known_hosts r471 committed by acolon@example.com <_mup_> Missing file from prev commit <_mup_> juju/ssh-known_hosts r472 committed by acolon@example.com <_mup_> Sample keys use a fake user, not my account <SpamapS> hazmat: would the txzookeeper tests be destructive to an existing zookeeper or does it use some kind of unique namespace so it won't trash whats already there? <SpamapS> hazmat: ahh, I see now.. its extremely dangerous! <SpamapS> hazmat: deletes the entire thing. Doh. <jimbaker> SpamapS, could use chroot for zk <SpamapS> jimbaker: I'd have to build another chroot, inside my chroot, to install zookeeperd. <jimbaker> SpamapS, no i mean in the connection descriptor for zk itself <jimbaker> (also called chroot) <SpamapS> jimbaker: makes *far* more sense for txzookeeper to spin up its own ephemeral zk and manage it. <jimbaker> SpamapS, sure. just an option <SpamapS> jimbaker: I don't understand zk or txzk enough to do that. :P .. just going to mark it as affecting the package so we know why we can't run the test suite on build. :) <jimbaker> SpamapS, no worries. but it's as simple as changing the connection string to append the desired root for the nodes to be put in <hazmat> SpamapS, yeah.. its dangerous, the chroot trick is just a matter of specifying the connection string a little different, but per the bug txzk should just setup the zk instance <hazmat> its already got the code todo so, just not been rewired into a an appros test layer. <SpamapS> hazmat: yeah, medium importance.. we'll get to it at some point but its not uber critical since txzk doesn't change that much. <SpamapS> hazmat: have you taken a close look at the quality fo the 'epsilon' python module used in txaws ? <SpamapS> hazmat: its kind of abandonware ... the usage is so thin too.. just some date parsing stuff that I'm sure is doable by something already in main... :p <SpamapS> actually, wow.. ISO8601 is like, the easiest date format ever to parse. <SpamapS> aha.. python-dateutil .. author: Gustavo Niemeyer. :) <nijaba> looks like https://code.launchpad.net/~nijaba/charm-tools/peer-replay/+merge/86721 is finally ready to be reviewed. it builds and runs nicely too :) <nijaba> if anyone got some spare time to review.. <nijaba> SpamapS: why do we need charms to work with lucid again? <SpamapS> nijaba: we don't need the charms themselves to work with lucid, but charm-tools we do. <SpamapS> nijaba: so we can technically just skip the charm helper test suites on anything before oneiric I suppose. <nijaba> SpamapS: can you elaborate? I thought we could only run guests which are oneiric or > <nijaba> SpamapS: ah, juju tools, not the helpers need to run on 10.04... makes sense * SpamapS patches dateutil in for epsilon and jumps for joy when all tests pass. <SpamapS> seems like we need to have a txaws release at some point soon. #juju 2012-01-06 <SpamapS> hazmat: https://code.launchpad.net/~clint-fewbar/txaws/drop-epsilon/+merge/87700 ... nice juicy txaws change for you to review. :) <hazmat> tasty <hazmat> SpamapS, nice <SpamapS> next on the hit list is pytz <hazmat> that ones harder <SpamapS> not really <SpamapS> only used for UTC <hazmat> not sure what the usage is, but as far as replacements.. <SpamapS> which dateutil also has <hazmat> cool <SpamapS> if we're going to pull txaws into main, might as well get txaws using the existing main stuff rather than expand main even further <hazmat> SpamapS, sounds good to me <hazmat> hmm.. utc support should be builtin <hazmat> oh.. its there for constant <hazmat> sad <hazmat> ah.. there tzinfo object instances <SpamapS> yeah, just need datetime.datetime.utcnow() <nijaba> I seem to run into cases where hooks are skiped when running juju on lxc. anyone seeing this? <SpamapS> hm, its not quite the same thing.. datetime.utcnow() will return a naive datetime.. I need it to be a UTC datetime <hazmat> SpamapS, as you said dateutil includes the nesc utc tzinfo impl <hazmat> nijaba, skipped ? or not observed ;-) <hazmat> nijaba, which hooks in particular (start/install)? <nijaba> hazmat: skipped as in state: running but obviously the install hook was never called <SpamapS> yeah exactly, just had to wrap my head around it <hazmat> nijaba, is the hook executable? <hazmat> nijaba, i'd check the unit agent log on unit's disk to verify, it will skip if not found <nijaba> hazmat: it is. and what's funny is that it happens when I start two unit of the same service in short time period. One does it fine, the other one does not * nijaba looks at the log <hazmat> nijaba, can you pastebin the unit agent log from one thats being skipped? <hazmat> nijaba, there shouldn't be any way for that to happen, to get to started it passes through install/start transitions which execute relevant hooks. i'm happy to take a look though <hazmat> SpamapS, its a drop in replacement for the imports UTC/tzutc, the only delta of note is the unit test <hazmat> for the FixedOffset test <SpamapS> hazmat: yeah, I don't even think I need dateutil .. as datetime.utcnow().replace(tzinfo=tzinfo('UTC')) seems to work fine <hazmat> SpamapS, cool.. i could have sworn it was builtin <nijaba> hazmat: ok, I think I know where it comes from. I started debug-hook before the unit was ready, went to have dinner, came back, the debug-hook timed out on the "accept key" prompt and installed was never actually run <SpamapS> hazmat: you get the UTC time, but to be identical, you need tzinfo to be set just like pytz does it <hazmat> "An object d of type time or datetime may be naive or aware. d is aware if d.tzinfo is not None and d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None, or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns None, d is naive." <nijaba> hazmat: http://pastebin.ubuntu.com/794426/ <hazmat> nijaba, ah.. so debug-hooks was running and exited, so the hooks where run and there was no start hook <hazmat> thats still a little odd <hazmat> ah the cli client connection to zk timed out, removing debug mode <hazmat> nijaba, did your laptop sleep or network get interuppted? <nijaba> hazmat: well, it is quite logical. for the unit, I was in debug hook mode, so nothing was run (was waiting for me to launch it). Since the session timed out before I got back, it continued without ever running it <nijaba> hazmat: nope, just left alone for 3h <hazmat> there isn't an explicit timeout on debug hook sessions, but if the client looses connectivity for any reason it is ended <hazmat> time for dinner bbiab <nijaba> hazmat: the time out is on the client side for me to accept connecting to a host with a new key <nijaba> is there a way to tell juju (lxc) to create the guest in a tmpfs ? Would speed up tests quite a bit I think <nijaba> gah, I'll just mount /var/lib/lxc/ in a tmpfs... <hazmat> nijaba, that should work <hazmat> nijaba, there's support in lxc-clone for snapshots but its not something we've explored <hazmat> on an ssd after the first unit (which also does the master template creation) takes just a few secs <hazmat> at least for me <hazmat> er.. template lxc container creation <nijaba> hazmat: sorry, only a good old spinner 7200rpm here :) <SpamapS> hazmat: indeed, dateutil.tz's tzutc == pytz.UTC and tzoffset ~= pytz.FixedOffset <nijaba> whaaa. That was fast! <nijaba> I have to be REALLY quick to be able to start juju debug-hook before the install hook is called * nijaba just added "tmpfs /var/lib/lxc tmpfs defaults,size=3G 0 0" to his /etc/fstab <hazmat> nijaba, yeah.. deploy really needs an option for running with debug-hooks to help against the install/start case <hazmat> ie.. deploy --debug <nijaba> hazmat: would be nice indeed * nijaba juju deploy local:bed && juju deploy local:nick && juju add-relation nick bed <SpamapS> hazmat: woot.. managed to replace pytz, zope.datetime, and epsilon with dateutil <hazmat> SpamapS, score <hazmat> nijaba, just don't destroy the env ;-) * hazmat hibernates <koolhead17> nijaba: the limesurvey charm has been very helpful 2 me in understanding charms writing :) <nijaba> koolhead17: I am glad :) <koolhead17> nijaba: will you have time to review my charm later in day? i am almost done with all the blockers you mentioned in the review. I need some more time to get mysql part talking!! :P <nijaba> koolhead17: If not today, I'll try this we. Ping me when you think you are good <koolhead17> nijaba: perfect. :) <koolhead17> i had accidently shutdown my machine while juju was still running and i kept getting this http://paste.ubuntu.com/794719/ <koolhead17> the only solution i found for this was to remove the files inside my data-dir <koolhead17> is it right way? <fwereade> koolhead17, I don't know for sure; but what do you get if you destroy-environment? <koolhead17> fwereade: well i got no solution even after trying that, so i applied the hard way :P <fwereade> koolhead17, fair enough -- so destroy-environment just didn't do anything? <koolhead17> fwereade: destroy-environment has worked for me in normal condition <fwereade> koolhead17, indeed, just not with a restart in between <koolhead17> this time my poor system hanged while juju was spawning some contaners <koolhead17> fwereade: i would say its my system issue and 4 that solution was what i did. :P <fwereade> koolhead17, well, glad it's fixed anyway ;) <koolhead17> fwereade: indeed!! :D <rbasak> Has anyone yet tried running juju on arm? <rbasak> I get http://paste.ubuntu.com/794755/ but not sure if it's an arm issue or it's me doing something wrong. <koolhead17> fwereade: i was going through my uunits.log and saw http://paste.ubuntu.com/794757/ is it okey? my charm is running well <nijaba> argh, looks like my lxc is stuck on something. Getting a weird error on juju destroy-environment http://pastebin.ubuntu.com/794769/ <koolhead17> nijaba: last time we were discussing about the possiblity of having a mail-server kind charm so we can simply use it for CMS <nijaba> koolhead17: yep. And I hinted that this may not be the only option we want to offer. it is often a better choice to point the CMS to an external SMTP server rather than forcing to deploy one in the juju environment <nijaba> koolhead17: which is what I did for roundcube and limesurvey <fwereade> koolhead17, I'm afraid I don't know about that at all :( <koolhead17> nijaba: yeah am going through the charm!! :P <koolhead17> nijaba: fwereade in my charm case, the mail server simply needed to send password reset msg. <nijaba> koolhead17: so either use a local smtp server or point to an external one <koolhead17> nijaba: okey. <koolhead17> nijaba: http://bazaar.launchpad.net/~charmers/charm/oneiric/limesurvey/trunk/view/head:/config.yaml i see information about the mailserver settings, i can use something equivalant <nijaba> koolhead17: yes, that's what I would suggest <koolhead17> nijaba: but i don`t see any of the mail server related package getting installed via Install file of the charm, am i missing something? * koolhead17 is bit confused :P <koolhead17> shit, we can use remote host for that as you suggested nijaba , stupid me <nijaba> koolhead17: right, but let's keep the s**t out :) <koolhead17> nijaba: :) <rbasak> running juju locally (lxc), juju is calling lxc is calling debootstrap without a proxy. Any idea how I can set one? debootstrap will accept an http_proxy environment variable AFAIK, but I don't know how to set it in the middle <koolhead17> nijaba: so limesurvey mysql db while imported in mysql db contains authentication credentials like user: admin password: password, i am reading the readme.txt? <nijaba> koolhead17: yes <koolhead17> nijaba: aah nice, which means we are importing the db and accordingly adding the credentials in its config file :) This makes me feel goooooooood <nijaba> looks like I hit a juju bug when I have an unbound var in a peer-relation-joined. once I have this condition, relation events won't be processed anymore until I restart my environment http://pastebin.ubuntu.com/794903/ <nijaba> hazmat: want me to open a bug for this ^? <m_3> reminder to update your lxc caches (P _and_ O) and whatever you need in apt-cacher-ng caches before travel <nijaba> m_3: may sound silly, but what are P and O lxc caches <m_3> nijaba: sorry, local juju deployment caches for precise and oneiric <nijaba> m_3: thanks, much clearer! <m_3> i.e., bootstrap and deploy something with each series so the base install gets built out <nijaba> rght <m_3> the harder one to handle is apt-cacher-ng... gotta spin up whatever charms you might wanna work with offline <_mup_> Bug #912812 was filed: Error condition on relation hooks locks events processing <juju:New> < https://launchpad.net/bugs/912812 > <hazmat> hmm <nijaba> hmhmm? <hazmat> nijaba, do you have the complete log for that unit agent <nijaba> hazmat: killed it, but will reproduced <hazmat> nijaba, cool, i think i've worked it out, thats a rather serious bug issue imo <nijaba> hazmat: looked like it to me. I opened a bug, if you did not see <hazmat> nijaba, got it just commenting on it now <nijaba> hmmm, looks like this bug is even worse than I thought. After destroying my env and bootstraping a new one, a new deploy seems to block <nijaba> short of rebooting my system, what do I need to wipe to restart from a clean state? <koolhead17> nijaba: i have fixed most of the blockers you mentioned in 1st review, if you have time please review it :) <koolhead17> https://code.launchpad.net/~koolhead17/charm/oneiric/owncloud2/trunk <nijaba> koolhead17: looking <nijaba> koolhead17: just our of curiosity, why in start are you using 'service apache2 start' and in stop '/etc/init.d/apache2 stop' ? just curious, as both should work, but would tend to use the same form in both. <hazmat> nijaba, huh? simplying destroying the env should resolve it <hazmat> actually just removing the unit would suffice, its a local unit problem <koolhead17> nijaba: :P lemme check it. <nijaba> hazmat: well, it might be something else, but my first unit in the new env has been pending for 15min now. it's a bit long for lxc in a tmpfs :( <koolhead17> nijaba: because i wrote that part long time ago :P just modified it <nijaba> koolhead17: your changes look good to me :) <nijaba> koolhead17: can't wait for the mysql part! <nijaba> koolhead17: do you want to wait for that until we promulgate? if not, please change the bug status to "fix-commited" and comment on the changes you made <nijaba> hazmat: you interested in my current lock state or should I go ahead an reboot? <hazmat> nijaba, yes i'd like a pastebin of the unit agent log in complete <hazmat> nijaba, oh the locked state, sure <koolhead17> nijaba: it currently works without any issue and uses sqlite, i will change it to fix-commited with comment that mysql integration part working with. <hazmat> nijaba, can you pastebin a ps aux process listing <nijaba> hazmat: sure <nijaba> hazmat: http://paste.ubuntu.com/795106/ <hazmat> nijaba, yeah.. i've seen that occasionally lxc-wait basically hangs.. <hazmat> lxc-wait -n nbarcet-lxc-roundcube-0 -s RUNNING <hazmat> nijaba, what's the output of lxc-ls ? <hazmat> that should show if the container is running <nijaba> hazmat: http://paste.ubuntu.com/795107/ * nijaba loves pastebinit <hazmat> nijaba, me too.. last one.. could you pastebin the machine agent log <nijaba> hazmat: the one in the unit? Can't ssh to it at this point <hazmat> nijaba, /home/nbarcet/tmp/juju/nbarcet-lxc/machine-agent.log <hazmat> nijaba, the unit log files are on local disk as well and symlinked in to the data-dir, although not sure that works across disk partitions like you've setup <SpamapS> nijaba: 11.10 or precise? <SpamapS> I believe there have been quite a few fixes to lxc in precise <nijaba> hazmat: http://paste.ubuntu.com/795113/ <hazmat> i think this is an lxc issue, but not one reported upstream yet <nijaba> SpamapS: 11.10 <hazmat> hmm.. so the container start fails, and then the lxc-wait hangs because the container isn't started <hazmat> i guess the question is why the container start failed, which should be in the container console log under /home/nbarcet/tmp/juju/nbarcet-lxc/units/roundcube-0/ <hazmat> nijaba, okay.. last one ;-) could you pastebin the files in that dir? <SpamapS> hazmat: and why lxc-wait doesn't return an error when start has failed. <nijaba> hazmat: http://paste.ubuntu.com/795117/ <hazmat> SpamapS, we should probably lxc-wait on more than just start to detect the failure and avoid the machine agent hang, the lxc processes have completed, but understanding why the container fails would be nice helpful as well <hazmat> hmm.. that looks normal <koolhead17> Is it a good idea to have charm for splunk? <nijaba> hazmat: arg... truncated by pastebinit <nijaba> hazmat: then end is not normal, wait a sec <nijaba> hazmat: http://paste.ubuntu.com/795123/ <SpamapS> hazmat: indeed.. RUNNING|STOPPED maybe? <SpamapS> koolhead17: the splunk server, yes. The splunk agent? not until subordinate services land (soon I think) <nijaba> SpamapS: splunk wa my first use case to justify "virtual" charms, which we now call subordinates ;) <jcastro> koolhead17: dude nice work there with owncloud <koolhead17> SpamapS: i have two questions, 1) it has separate pkg for 32 and 64 bit. 2) it asks you to fill company details your name before it lets you download them actually. How to overcome this part :D <jcastro> we just need the mysql parts right? <koolhead17> jcastro: thanks sir!! <koolhead17> jcastro: yes i will get it hopefully by monday/tuesday. <SpamapS> nijaba: I actually don't think they're at all similar, virtual and subordinate. We just happen to be able to mimic the end-result of virtual charms using subordinate ones.. but I'm still not really "happy" with that sort of hack. :p <nijaba> jcastro: actually, I think we can promulgate as is, without the mysql part, as the limit is clearly stated in the readme. do you agree? <SpamapS> nijaba: a virtual service would be a charm that doesn't need a machine... so the hooks would run once, in one place. using a subordinate charm, we have to run the hooks on every machine that gets related to it..and, IMO, they will end up being more complicated. <jcastro> I agree, I mean, if it's for personal use, I don't need mysql <jcastro> the person who wants to deploy it for tons of users will want mysql and will find the bug report and/or fix it. <koolhead17> jcastro: i can write saperate charm for mysql if its good idea :P <jcastro> but we do have a bug on the charm for mysql <nijaba> SpamapS: well, not really, as long as we do not have to start a container for it, I think it is the right way to go after quite a bit of brainstorming with jimbaker <jcastro> koolhead17: config option? <koolhead17> jcastro: currently it just works with sqlite <nijaba> jcastro: what bug for for mysql? <SpamapS> nijaba: this means that for an ELB charm, you have to copy the ELB credentials to every single machine. <hazmat> SpamapS, yup re RUNNING|STOPPED <nijaba> koolhead17: yes, we want to avoid duplicating charms, use config options instead <jcastro> nijaba: oh hey, check this out: https://code.launchpad.net/~marcoceppi/charm/oneiric/owncloud2/mysql <nijaba> SpamapS: why not provide them in config? <jcastro> here we go, nijaba, let me find marco and see if that's review worthy <SpamapS> nijaba: they'll be in config.. and copied, to *every* machine. <jcastro> and we'll just fix it <SpamapS> nijaba: a virtual charm would have those credentials isolated to a single machine, most likely a provisioning machine. <SpamapS> I realize this is moot while we have no ACL isolation for ZK <hazmat> nijaba, thanks thats helpful <SpamapS> nijaba: its a workaround, not a solution, thats all. <nijaba> SpamapS: agreed <nijaba> hazmat: np * nijaba reboots <SpamapS> Most places currently have similar problems.. root on any puppet box can read the entire corpus of puppet manifests and files in the puppet master. <hazmat> SpamapS, really? <hazmat> so they get transport level security with certs but no resource access granularity ? <SpamapS> That may be different now.. <SpamapS> but in the past, it was true, the cert process was just to verify that you were allowed to read the puppet manifests and files <SpamapS> Its then entirely up to your puppet run to do whatever you will with that information. <_mup_> Bug #912879 was filed: Machine agent hangs if lxc container start fails <juju:New> < https://launchpad.net/bugs/912879 > <SpamapS> hazmat: the key difference between that and our ZK problem is that its global *read* <hazmat> ic <koolhead17> SpamapS: splunk asks you to register an account to download there pkg, do u think its good idea to work on its charm? <nijaba> koolhead17: <Canonical hat on>I have add some discussion with them, so I would wait for subordintate to land and discussion to conclude<canonical hat off> <SpamapS> koolhead17: IMO, no, I'd focus on 100% open source software .. <nijaba> s/add/had * hazmat lunches <nijaba> bon appetit <koolhead17> SpamapS: nijaba thanks. :) <nijaba> koolhead17: just promulgated your owncloud charm! <nijaba> jcastro: blogging material? ^^ <jcastro> yep <jcastro> already working on it <jcastro> Friday, close to EOD? That's when all the new charms land. <jcastro> :) <SpamapS> wow.. ZK's internal test suite is pretty comprehensive <SpamapS> jcastro: friday is hack day. :) * nijaba hopes secretly that it will also be a bit of a review/merge day for SpamapS :] * koolhead17 kicks himself, why on earth he was not aware about pastebinit <nijaba> SpamapS: it looks like we may have an issue with versioning in charm-helppers-daily: the last daily build failed because of that... <jcastro> SpamapS: hey, can you do a "charm get owncloud" and tell me what happens? <jcastro> mine comes up with an empty bzr branch?! <SpamapS> jcastro: you did something wrong.. or charm tools is broke <SpamapS> jcastro: works fine for me <SpamapS> $ charm get owncloud <SpamapS> Branched 8 revisions. <jcastro> nm, I am not able to reproduce <jcastro> weird <jcastro> ok so this threw me off <jcastro> koolhead17: the charm is "owncloud" <jcastro> but the service is owncloud2 <koolhead17> jcastro: it
{'channel': 'juju', 'month': 1}