#juju 2011-11-01 <marcoceppi> o/ <ejat> environments.sample.default-series: required value not found ??? <uksysadmin> anyone familiar with openstack and juju? <uksysadmin> I've a physical 2 node cluster which I can successfully launch instances. juju fails though with "nomorenetwork" error <uksysadmin> any pointers appreciated <noodles775> uksysadmin: I hadn't heard that juju supported openstack yet... let me check the faq. <uksysadmin> yeah was using it last week under vbox - moved to a v small multi node set up on my desk <uksysadmin> only difference was that my vbox environment was painfully slow but it bootstrapped ok and launched other stuff no problem <uksysadmin> I've a feeling its a specific openstack issue - but I can allocate floating ips to my instances <noodles775> uksysadmin: have you tried using lxc instead? (I just tried it yesterday and it was pretty fast, even on my netbook... I just followed the example with 2 wordpress app servers and a mysql server) <uksysadmin> its not so much me wanting juju, openstack demos are my primary goal. <uksysadmin> just handy that I got wordpress going running openstack under vbox and all I've done is moved to some physical machines <noodles775> I see. <statik> hola <statik> Is there a way to have multiple environments defined in juju and specify on the CLI which one to use? I was trying to add an lxc environment to my juju config and am getting an error <statik> ERROR There are multiple environments and no explicit default (set one explicitly?): /home/emurphy/.juju/environments.yaml <statik> I haven't been able to find instructions in the docs on how to set a default or select an environment <robbiew> bcsaller: ^? <bcsaller> statik: most juju commands take a -e environment argument or you can add a default: env_name at the top level of the ~/.juju/environments.yaml file <statik> bcsaller, thanks! <noodles775> statik: I saw you've already got your answere, but just came across this too http://askubuntu.com/questions/65364/how-can-i-configure-multiple-deployment-environments-for-juju <statik> noodles775, thanks! I didn't think to look on askubuntu <zematynnad> hello - I'm going through the tutorial at https://juju.ubuntu.com/docs/write-charm.html . I've gotten to the point where I've fixed the intentional error in my localfile and update the revision number. But for some reason when I run the command $ juju upgrade-charm --repository=examples/ drupal, I get the following error: http://paste.kde.org/140630/ <zematynnad> has anyone run into this already? or know if the docs need to be updated perhaps? * ejat pokes SpamapS #juju 2011-11-02 <SpamapS> ejat: hey are you still here in Orlando? <ejat> SpamapS: yeah ... im still here ... <ejat> hopefully will see ya in the juju session this evening <lynxman> hazmat: ping <ejat> lynxman & hazmat : u guys at UDS ? <lynxman> ejat: yes :) <ejat> hopefully can meet ya ! :P <lynxman> ejat: so... how do you look like? ;) <ejat> hmm .... specky with jeans short pan for today .. <ejat> im in bonaire2 now ... maybe see ya in juju session this evening <lynxman> ejat: oh definitely :) <ejat> a lot of thing need to be learn from u guys .. <lynxman> ejat: we're around in case you need anything, I'm in a blue polo with a black jacket :) <lynxman> ejat: right now in bonaire 7, next in bonaire 4 for a session I'm leading <ejat> ill be at ya session after this .. <lynxman> ejat: cool :) <hazmat> lynxman, pong * ejat pokes SpamapS <SpamapS> juju session on config management right now at uds http://summit.ubuntu.com/uds-p/meeting/19431/servercloud-p-cfjuju/ join #ubuntu-uds-bonaire4 <ejat-> 0/ <marcoceppi> Weird issue with Juju deploy <marcoceppi> http://paste.ubuntu.com/726691/ <marcoceppi> This command was working yesterday, but stopped working this morning after adding a config.yaml <marcoceppi> Similar to what zematman was having <zematynnad> marcoceppi: what was the error you were getting? <marcoceppi> Charm 'local:oneiric/tf2' not found in repository /home/marco/Projects/juju/charms <marcoceppi> zematynnad: Similar to the one you were getting, only this is during a deploy <zematynnad> marcoceppi: the problem I had may not be the same as yours but here's what fixed mine... <marcoceppi> I'm all ears <marcoceppi> or eyes <zematynnad> marcoceppi: I got rid of revision in the yaml file and put the revision in a revision file <marcoceppi> Hum, I don't have a revision in the yaml file <zematynnad> marcoceppi: the revision number has to be a regular integer 1, 2, 3 instead of 1.1 or something like that <marcoceppi> Right, the revision number in revision is 3 currently <marcoceppi> Maybe I did something wrong in the config.yaml file? <zematynnad> I'm not sure but probably what' happening is that the error message is a bit generic and there's some syntax error or typo somewhere that needs to be fixed <marcoceppi> Probably a syntax error in config.yaml <marcoceppi> I was just asking m_3 that <marcoceppi> Thanks zematynnad I'll take a look at the config <zematynnad> marcoceppi: good luck! <m_3> marcoceppi: is it a good time to work on steam? #juju 2011-11-03 <marcoceppi> m_3: This charm is getting real close to completion <pindonga> hi, i'm trying out juju with the local provider. I managed to get it running but I think i found a bug, and wanted to discuss it with someone to see if I should file one <pindonga> when bootstrapping, juju tries to start dnsmasq, but I'm already running dnsmasq as a caching dns server <pindonga> so juju fails to start it again, and (I think) therefore fails to start zookeeper (as this one is not running either) <pindonga> when I stop dnsmasq things start to work <hazmat> pindonga, ping <pindonga> hey hazmat <pindonga> so I found these 2 problems (they may be related) <pindonga> 1. zookeeper not running after I reboot <pindonga> the only way I could get it to start was by removing the whole environment <pindonga> and starting from scratch <pindonga> 2. I *think* dnsmasq may be getting in the way but I 'm not sure <hazmat> pindonga, at the moment local environments do not survive reboot or ... even hibernation <pindonga> hazmat, is there anything we can do to work around that? <hazmat> the reboot issue is a little more interesting, we're working on the hibernation one <hazmat> pindonga, we could probably right an upstart job to capture the restart of the containers and lxc for reboot <hazmat> worth a bug report for the reboot scenario <hazmat> pindonga, regarding the networking .. indeed libvirt does drive a dnsmasq that is needed for getting the containers networked properly <hazmat> pindonga, its not clear to me that an existing dnsmasq is nesc fatal to that <hazmat> since the libvirt dnsmasq is binding the the bridge address <hazmat> worth some investigation to see what the conflict there might be <hazmat> pindonga, could you elaborate on the usage of the existing dnsmasq server <hazmat> just a local caching dns server bound to ? <pindonga> hazmat, I'm not sure it's conflicting, it may just be the zookeeper issue <pindonga> hazmat, but I'll try to reproduce and let you know <_mup_> Bug #885701 was filed: juju fails to bootstrap when dnsmasq already running <juju:New> < https://launchpad.net/bugs/885701 > <pindonga> hazmat, this is the dnsmasq bug: https://bugs.launchpad.net/juju/+bug/885701 <_mup_> Bug #885701: juju fails to bootstrap when dnsmasq already running <juju:New> < https://launchpad.net/bugs/885701 > <hazmat> pindonga, thanks <pindonga> hazmat, I just tried to deploy a basic charm (one that does nothing) to get access to a bare lxc instance <pindonga> when doing ssh to it it takes forever <hazmat> pindonga, are you at uds? <pindonga> do you know how I can debug this? to figure out what it's doing? <pindonga> yes <pindonga> you're here too? I can meet you <hazmat> pindonga, i'm sitting near the entrance the four chairs around the big red leather square <pindonga> k, I'll be there in a few minutes <hazmat> in the conference building <pindonga> thx <hazmat> pindonga, np <hazmat> pindonga, i have the blue hat on <_mup_> juju/local-repo-log-broken-charm r412 committed by montgomeryrobert@example.net <_mup_> local repo warns about broken charms <pindonga> hazmat, ping again (sorry).. I think I messed something up now... I reinstalled lxc, and now I get an error about lxc-ubuntu not being found <pindonga> so I guess I have the wrong version of lxc (but I installed it via apt-get, so it should have gotten the right one, right?) <pindonga> hazmat, ping again (sorry).. I think I messed something up now... I reinstalled lxc, and now I get an error about lxc-ubuntu not being found <jimbaker> juju roadmap discussion now in #ubuntu-uds-bonaire7 <mpl> so I don't suppose there would be some EC2s and S3s available somewhere so that one can play around with juju and test it? <noodles775> mpl: you can actually test locally without EC2... have you seen the following section of the documentation? <noodles775> https://juju.ubuntu.com/docs/provider-configuration-local.html <mpl> noodles775: yeah I have. it failed for me. <noodles775> mpl: at what point? There were a few teething issues when I tried it, but got it working... * noodles775 looks for the email summary. <mpl> mpl@yggdrasil:~$ juju bootstrap <mpl> 2011-11-03 18:44:09,642 INFO Bootstrapping environment 'local' (type: local)... <mpl> 2011-11-03 18:44:09,643 INFO Checking for required packages... <mpl> 2011-11-03 18:44:09,848 INFO Starting networking... <mpl> 'module' object has no attribute 'check_output' <mpl> 2011-11-03 18:44:09,849 ERROR 'module' object has no attribute 'check_output' <noodles775> mpl: and that's using juju from the PPA on Ubuntu oneiric? (if so, it's different to the issue I had - but the juju team should be back from lunch in a while) <noodles775> mpl: here's a summary of the small issues and workarounds I had, in case it helps: https://lists.ubuntu.com/archives/juju/2011-October/000901.html <mpl> noodles775: ppa <mpl> yeah I suspected 1) could be an issue. I haven't rebooted. and don't intend to right now. <therve> heya <therve> I'm getting DNS error on store.juju.ubuntu.com when trying to use juju deploy, any idea? <noodles775> therve: yeah, I'm guessing you haven't specified the --repository correctly (or haven't prefixed with local:charmname) as per the docs. <noodles775> (and therefore it tries to use an as-yet non-existent online repository. <therve> noodles775, ok, that sounds like a good idea <therve> noodles775, but then it can't find the local charms somehow <noodles775> therve: I'm not sure if the docs are out of date, but you need to have your charm under a distroseries (oneiric). <noodles775> as in /home/therve/charms/oneiric/mycharm/hooks etc. (from memory) <therve> noodles775, ah, thanks! I was specifying the oneric/ as repository indeed <noodles775> Great. <mgw> still having trouble getting my VMs up and connected to cobblerâ¦ anybody have a minute to help? <_mup_> Bug #885905 was filed: Obsolete metadata warning doesn't indicate the charm <juju:New> < https://launchpad.net/bugs/885905 > <_mup_> Bug #885906 was filed: "Try it yourself" on wiki front page doesn't give next action <juju:New> < https://launchpad.net/bugs/885906 > <mgw> is there a way to bootstrap an existing vm into cobbler/juju, rather than doing a fresh install of ubuntu for every system? #juju 2011-11-04 <mgw> Heyâ¦ anybody know how to run juju.preseed on an already deployed server? * PandorBox dropped juju for plain cloud-init yesterday <marcoceppi> PandorBox that's a shame <PandorBox> marcoceppi: it's a really nice concept, but was getting in the way of deploying stuff... something for later I suppose <_mup_> Bug #886188 was filed: No feedback when creating master container <juju:New> < https://launchpad.net/bugs/886188 > <_mup_> Bug #886195 was filed: Crash in update_state <juju:New> < https://launchpad.net/bugs/886195 > <_mup_> Bug #886207 was filed: juju-log messages not showing up in debug-log <juju:New> < https://launchpad.net/bugs/886207 > <_mup_> Bug #886210 was filed: update https://juju.ubuntu.com/docs/write-charm.html to reference juju <juju:New> < https://launchpad.net/bugs/886210 > <_mup_> Bug #886215 was filed: scaffolding like tooling for writing charms <juju:New> < https://launchpad.net/bugs/886215 > <_mup_> Bug #886216 was filed: doc bug: explain metadata and hooks before getting into "writing a formula" in the docs <juju:New> < https://launchpad.net/bugs/886216 > <_mup_> Bug #886232 was filed: Backtrace in juju debug-log when destroying a service <juju:New> < https://launchpad.net/bugs/886232 > <_mup_> Bug #886364 was filed: default-series ignored in environments.yaml <juju:New> < https://launchpad.net/bugs/886364 > <mgw> heyâ¦ any experienced juju users here? #juju 2011-11-06 <rog> yo * rog likes free wi-fi in airports. +1 to Orlando. <SpamapS> Indeed, the free wifi was cool, though it seemed to trigger some bug in the wifi drivers on my air <SpamapS> lots of crashing <SpamapS> iphone worked fine :p * SpamapS always feels giddy on inflight wifi <ejat> morning .. <ejat> alo .. #juju 2011-11-07 <hazmat> g'morning * niemeyer waves <hazmat> niemeyer, g'morning <niemeyer> hazmat: Heya <pindonga> morning... so I am trying to use juju for managing lxc containers for development (I know this is not the primary use case for it) <pindonga> the problem I'm facing is that containers do not survive a reboot (I have to destroy the whole env and rebootstrap) <pindonga> I know this is a known issue, but I was wondering if there is a workaround for it * noodles775 is interested too. I thought by putting my juju-dir somewhere other than /tmp I could avoid that. <hazmat> hmm <pindonga> noodles775, no, I have my data-dir in /home and this is still the case <pindonga> btw I'm running a freshly installed oneiric <hazmat> so there are two issues here, one for hibernation (which is problematic in a different way) and one for reboot, the first one is a work in progress, the second one doesn't have a workaround, it can be done by hand though, albeit its a pretty tedious process <pindonga> another issue I have is that I don't get lxc containers to start (for some reason cgroup is not mounted automatically by juju) <hazmat> it requires starting zookeeper by hand, and the machine agent, and then starting all the containers <pindonga> hazmat, is this written down somewhere? <hazmat> juju will need to write out an upstart job per environment to make this a bit cleaner <hazmat> and automatic <hazmat> pindonga, its not written down, i'm finishing up an email atm, i'll see if i can put together a workaround after <pindonga> hazmat, awesome <pindonga> hazmat, another thing: can you think of a reason why the cgroup is not mounted automatically by juju? <pindonga> may it be that I bootstrapped using distro-series: lucid? (I'm running on oneiric though) <hazmat> pindonga, only the host distro matters regarding the cgroup mount, and juju doesn't handle mounting it, it should be automatic though <pindonga> hazmat, automatic as in? if juju doesn't handle it, does lxc handle it? do I need a cgroup entry in /etc/fstab? <hazmat> pindonga, automatic as its handled by the cgroup-bin package's upstart job <hazmat> pindonga, see /etc/init/cgconfig <hazmat> pindonga, it does not need to be in fstab <pindonga> hazmat, don't have that file., but I have /etc/init/cgoup-lite <pindonga> I run cgroups-mount manually and it's now mounted I think <hazmat> pindonga, yeah.. i think the other one might have been an old natty file.. cgroup-lite looks correct * hazmat pokes at the packages <hazmat> ah.. ic. cgroup-lite is a minimal set which can support lxc, cgroup-bin also suffices for lxc but has additional cgroup tools <pindonga> ok, got one container up \o/ <pindonga> however, the sources file still reads oneiric as the distro <pindonga> :( <pindonga> even though I had lucid in environemtns.yaml * niemeyer => lunch <hazmat> pindonga, yeah.. there was a bug filed about that <hazmat> bug 886364 <pindonga> ah, ok <_mup_> Bug #886364: default-series ignored in environments.yaml <juju:New> < https://launchpad.net/bugs/886364 > <pindonga> tx <brtsz> hi guys <hazmat> brtsz, greetings <hazmat> pindonga, i'm looking at what a workaround would take, doesn't seem like its something that's doable cleanly as a manual script it would need some patching of libraries to record port information, better to just implement per desired direction of using upstart <pindonga> hazmat, yeah... I think I found a workaround for the time being <pindonga> just use plain lxc without juju for my dev lxc containers :) <pindonga> as I don't need juju really for that <pindonga> it was just nice to have it manage my lxc containers too <pindonga> thanks for the help though, it's been really useful so far <hazmat> pindonga, np * hazmat lunches <noodles775> Is this a known bug? (specifying a config.yaml results in charm not being found, move it out of the way and it deploys): http://paste.ubuntu.com/731083/ * noodles775 can't see any bugs on bugs.launchpad.net/juju for config.yaml <_mup_> Bug #887194 was filed: charm not found on config.yaml parse error <juju:New> < https://launchpad.net/bugs/887194 > <hazmat> noodles775, it was reported with a fix in bug 885515 <_mup_> Bug #885515: More verbose error when issue occurs in config.yaml <juju:In Progress by hazmat> < https://launchpad.net/bugs/885515 > <noodles775> hazmat: ah, nice (LP's bug search didn't turn it up, but great that the fix is there already :) ). <hazmat> noodles775, not merged yet, but yeah.. should be in soon * noodles775 marks his new bug as a dupe. <hazmat> jimbaker, ping <hazmat> hmm.. riak didn't make the hot and hairy list <nolan_d> I'm trying to understand Juju. I'm in a situation where we have a bunch of servers we'll wish to deploy various services on, and I'm wondering if I should recommend it. <nolan_d> Is it still limited to one service per machine as a FAQ I read seems to state? <nolan_d> Feel free to tell me to RTFM, I just need to find a FM to read. :) The one on the Ubuntu wiki seems a bit fragmentary and doesn't really address my questions. <nolan_d> Also, how does it handle the situation where I might want to, say, host a bunch of services at various domains on a cloud? "expose" is nice, but does it give me any way to say "expose this service at this domain/port/service type?" <nolan_d> Back later. <jcastro> https://plus.google.com/b/103184405956510785630/103184405956510785630/posts <jcastro> juju G+ page is up! <hazmat> jcastro, nice <jcastro> adding videos <jcastro> as soon as I figure out how to make it a team manageable page I'll let you know. :) #juju 2011-11-08 <hazmat> niemeyer, g'morning <niemeyer> hazmat: Hey! * hazmat is up early to take out the afternoon for a dentist <hazmat> fwereade, rog greetings <ejat> morning hazmat <fwereade> mornings :) <rog> hazmat, fwereade, niemeyer: hey! <rog> i saw previous exchange but unity had crashed so i couldn't type anything <rog> guess what, i've installed oneiric <rog> (probably my fault though for trying to tweak things with ccsm) <hazmat> fwereade, thanks for having a look <hazmat> at the txzk stuff <_mup_> txzookeeper/session-and-conn-fail r62 committed by montgomeryrobert@example.net <_mup_> save the chaos monkey via s/loose/lose ;-) <_mup_> txzookeeper/session-and-conn-fail r63 committed by montgomeryrobert@example.net <_mup_> simplify pass through property, reenable retry function test, use min() instead of condition, per review comments <_mup_> txzookeeper/session-and-conn-fail r64 committed by montgomeryrobert@example.net <_mup_> verify session event sequence per review comment <_mup_> juju/session-expiration r408 committed by montgomeryrobert@example.net <_mup_> incorporate session expiration in process handling and retry client <_mup_> juju/local-repo-log-broken-charm r413 committed by montgomeryrobert@example.net <_mup_> metadata parse enriches yamlerror with path info * hazmat wishes lp bug search would handle comments <andylockran> hey guys - I'm looking to work out how best to organise a system for managing my ubuntu installations. <andylockran> What resource should I look at to find more about running a management system on my own private infrastructure? <hazmat> andylockran, that sounds like a question better suited to #ubuntu-server .. it depends on what your looking for re 'management', if you mean deployment automation orchestra is nice, if you mean automated machine management, there are a number of closed and opensource tools that might fit the bill from landscape to puppet.. juju itself is focused at a higher level of service management and orchestration <jcastro> SpamapS: hey don't forget to ask scale-buddy of yours about Charm School <jcastro> yes, charm school. <SpamapS> :) <_mup_> Bug #887644 was filed: juju/go: fixes for new error interface <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/887644 > <noodles775> oooh, golang now in juju - I'd not realised it had started already :) <rog> noodles775: early stages yet! <robbiew> noodles775: ...and not targeted for production release in 12.04 ;-)...but should be a sweet tech preview for sure <robbiew> m_3: ping * hazmat yawns <hazmat> fwereade, reply sent * hazmat heads off to discover the tender mercy of a dentist <bloodearnest> hey folks <bloodearnest> using lxc provider, juju ssh is giving me an error: "PTY allocation request failed on channel 0" <bloodearnest> it worked fine while at UDS last week <jimbaker> bloodearnest, this seems to be a common problem out there, in terms of googling on that error. i haven <jimbaker> 't seen it myself however <jimbaker> eg, http://blog.asteriosk.gr/2009/02/20/pty-allocation-request-failed-on-channel-0/ discusses this issue <bloodearnest> jimbaker, hey, yeah googling suggests somthing incorrect with /dev/tty setup <bloodearnest> jimbaker: strange thing is it worked all last week fine :( <jimbaker> bloodearnest, precisely. i don't think it has anything to do with our lxc stuff, other than it seems like a possible resource exhaustion issue <bloodearnest> jimbaker: k, I'll try a reboot and see if that clears it up. Been a while anyway... :) <jimbaker> bloodearnest, ok, well that can fix some issues like this, but not ideal of course <jimbaker> but it will tell something <bloodearnest> jimbaker: any other route you'd suggest? I double check running processes, but nothing seemed awry <jimbaker> bloodearnest, from what i read on the problem, that would not be an issue <bloodearnest> jimbaker: lsof | grep lxc tells me that a single lxc-start has /dev/pts/[2-6] open <jimbaker> bloodearnest, but that's a very minimal number of ptys to have open <bloodearnest> jimbaker: yep <_mup_> juju/support-num-units r412 committed by montgomeryrobert@example.net <_mup_> Support in juju add-units <bloodearnest> jimbaker: fwiw, reboot didn't help. Fresh environment, trivial charm, still no ssh :( <bloodearnest> jimbaker: gotta EOD, but thanks for your help! <rog> niemeyer: here's a first skeleton of the juju provider-independent tests interface. <rog> http://paste.ubuntu.com/732246/ <jimbaker> bloodearnest, just pointing out some possibilities. easier if i had the problem myself :( <rog> comments welcome <niemeyer> rog: I don't understand what the interface is doing there <bloodearnest> jimbaker: sure - thanks anyway :) <rog> niemeyer: it's to enable a given environ provider to run a set of standard juju tests against itself <rog> niemeyer: as we discussed AFAIR <niemeyer> rog: what about testProvider(provider)? <rog> niemeyer: i wanted to do that, but gocheck makes it hard. <niemeyer> rog: It's a function..? <rog> because gocheck registration is global <rog> maybe we could fix that, but i thought i'd try to work within existing constraints first <niemeyer> rog: It's even easier than that.. <niemeyer> rog: Create a suite, and simply register it for each provider <niemeyer> rog: Suite(&ProviderSuite{theProvider}) <rog> not so easy. but i've no time to do explain now, gotta go. <niemeyer> rog: and all the tests will be run independently with the provider set <niemeyer> rog: Duh <rog> two places need to call TestingT <niemeyer> rog: Nope <rog> because we've got two totally independant sets of tests <niemeyer> rog: They're simply two suites <rog> yes, that's what i want <niemeyer> rog: Suite(&ProviderSuite{provider1}) <rog> but who calls TestingT <niemeyer> rog: Suite(&ProviderSuite{provider2}) <rog> ? <niemeyer> rog: A single independent function, like all uses of gocheck <rog> should jujutest call TestingT? <rog> i didn't think it should, but perhaps that's the way to go <niemeyer> rog: Not sure about who's jujutest <rog> jujutest is called by a provider <niemeyer> rog: The provider package should do it <niemeyer> rog: I'd have to know more about the structure to help in that case <rog> ok, then how does jujutest register its test suite? <niemeyer> rog: It's feeling more complex than it ought to be.. <niemeyer> rog: I don't know who's jujutest <rog> niemeyer: jujutest is the platform-independent testing part of juju <niemeyer> rog: All the tests of juju are platform independent <rog> niemeyer: i don't want it to be part of juju itself because it's only about testing <niemeyer> rog: Let's talk about that when you have more time <rog> yeah, speak tomorrow <niemeyer> rog: Have a good one <rog> niemeyer: will do. and you! <pindonga> hey again, I have an lxc specific question, but maybe you can help me out anyway? I have created an lxc container, which I was able to log in successfully, however after applying updates (it was a fresh lucid install) it now no longer completes booting, and I have no idea how to find out why <pindonga> I managed to get some log output from it, but not very enlightening <pindonga> it looks like if init never spawns the getty processes <pindonga> and I see this: <pindonga> init: ureadahead-other main process (31) terminated with status 4 <pindonga> init: console-setup main process (32) terminated with status 1 <pindonga> init: ureadahead-other main process (37) terminated with status 4 <SpamapS> pindonga: I'm not sure lucid is going to work... LXC was pretty new then. <pindonga> SpamapS, I just found out something interesting <pindonga> I configured network manually with a static address <pindonga> ssh comes up ok <pindonga> but the console does not <pindonga> which even if it's broken works for me <pindonga> I use the lxc container as a glorified chroot :) <SpamapS> pin/whois pindonga <SpamapS> hahahaha doh <pindonga> \o * pindonga waves <SpamapS> wondered if we met last week ;) <SpamapS> pindonga: so are you running juju inside an LXC container, spawning more LXC containers? <pindonga> no, no *that* crazy :) <pindonga> in the short term I just tried to use juju to manage my lxc instances <pindonga> so I can do development in an isolated environment <pindonga> however, juju+lxc doesn't survive reboots yet <pindonga> so I moved onto just using plain lxc <pindonga> in the long term I want to move all of our infrastructure to juju (lxc locally and openstack for deployments) * hazmat catches up <hazmat> bloodearnest, so completly allegorical, i had some issues with pty allocation for ssh on lxc, reboots would help.. but once it failed it would never work, they did effectively disappear though i yanked my virtualbox install and kernel modules.. i'd be curious to look at your lsmod output <hazmat> jimbaker, ping <hazmat> pindonga, this isn't really juju related, but you can start the container with a debug log and pass cli options to /sbin/init (ie. upstart) to verbose log as well, that might help... imo, its probably just better to focus on 11.10 with eye to deploying 12.04 lts ... but if you really want it ;-) <pindonga> hazmat, yes , I was montgomeryrobert@example.net... thx <jimbaker> hazmat, hi <jimbaker> coffee time, biab <hazmat> jimbaker, priv msg <_mup_> juju/support-num-units r413 committed by montgomeryrobert@example.net <_mup_> Support in juju deploy <hazmat> jimbaker, nice <SpamapS> can we make the bot also tell us when trunk is committed to? <_mup_> juju/support-num-units r415 committed by montgomeryrobert@example.net <_mup_> PEP8, PyFlakes <_mup_> juju/support-num-units r416 committed by montgomeryrobert@example.net <_mup_> Better help output for CLI changes <hazmat> SpamapS, its client side, the code is avail <hazmat> although its erlang as i recall, not sure where its deployed <andylockran> hazmat: thanks for your tip. Ok - I'll look into that - thanks. <hazmat> SpamapS, https://launchpad.net/mup <hazmat> andylockran, np #juju 2011-11-09 <SpamapS> Heh.. seems like we should write a Gobot <SpamapS> http://www.toyarchive.com/Gobots/GobotsPic2.gif <SpamapS> tho we might get into some hairy trademark area ;) <_mup_> Bug #887919 was filed: Juju environment option to specify SSH key? <juju:New> < https://launchpad.net/bugs/887919 > <rog> fwereade: mornin' <niemeyer> Yo <hazmat> g'morning <fwereade> heya rog, niemeyer, hazmat <rog> niemeyer, hazmat: mornin' <rog> niemeyer: somewhat simpler jujutest package interface: http://paste.ubuntu.com/733042/ <niemeyer> rog: Why is that needed? <rog> niemeyer: where do the tests get defined? <niemeyer> rog: As far as I understand, we only need a type <rog> niemeyer: that's the type <niemeyer> rog: ProviderTests <rog> i though jujutests.Tests <niemeyer> rog: and what's Name and Value for? <niemeyer> rog: This should be within the tests as far as I understand <rog> niemeyer: it's so we can write tests that call Open twice to check persistance of a juju session <niemeyer> rog: am I missing something there? <rog> another possibility would be to pass ProviderFactory func() juju.Provider <niemeyer> rog: Hmm, no that sounds fine <niemeyer> rog: But I still don't get what's Value <niemeyer> rog: Is it Config? <rog> niemeyer: yeah, that would be a better name <niemeyer> rog: Aha, I see the picture now, thanks <niemeyer> rog: +1 <rog> cool <rog> niemeyer: i think i'll stick with Tests as a name until we want more than one suite. <niemeyer> rog: Sounds good <marcoceppi> Is there any way, during config-changed, to extract the value prior to change? <marcoceppi> Good morning, btw <niemeyer> marcoceppi: Morning <niemeyer> marcoceppi: Not with a standard variable, but you can do that trivially by storing the values you got in the last hook call <marcoceppi> Okay, so I would have to implement it myself then, thanks! Didn't want to duplicate efforts <niemeyer> marcoceppi: Yeah, we thought for a while about how we might do this, but in the end it feels like the simplicity of the current approach is worth the extra trouble in the cases something like this is interesting <niemeyer> marcoceppi: There is also the possibility that the configuration will change _twice_ before config-changed is called <marcoceppi> I don't think it's really important for the majority of cases <niemeyer> marcoceppi: So it would not be honest if we promised to give you _the last value_ <marcoceppi> Right <niemeyer> rog: "error" <3 <rog> niemeyer: great innit? <niemeyer> rog: Totally <rog> niemeyer: reviewing those gocheck changes by any chance? <niemeyer> rog: If that's not bothering you right now, I'd like to keep focused on this stuff <rog> niemeyer: that's fine <niemeyer> rog: Actually, the gocheck ones might see a review sooner <niemeyer> rog: Since I'll need them too <rog> niemeyer: that's the only significant one <niemeyer> rog: Super <rog> the others are just gofix + a few minors <niemeyer> Cool <niemeyer> Let me do that now <niemeyer> Actually, let me reboot to sync a kernel upgrade <niemeyer> brb <hazmat> new aws region this morning <rog> niemeyer: what's the best way to cope with the fact that actual ec2 tests need private keys that we don't want to give to everyone? <niemeyer> rog: As far as the provider test stuff we've been discussing goes, the first batch of tests is actually unity rather than integrational <niemeyer> rog: So you can put anything as a pair <niemeyer> rog: We just need to ensure the signature matches <rog> niemeyer: i'm not sure i know what you mean by "unity". do you mean that we won't actually talk to ec2 itself? <niemeyer> rog: Yes <niemeyer> rog: None of the unit tests in juju talk to the real services <rog> niemeyer: but i want to check that my code actually works with ec2 before writing the other tests! <niemeyer> rog: You can have a set of tests which is integrational as well.. that'd be nice <niemeyer> rog: But not enough by itself <rog> niemeyer: necessary, i think, but not sufficient. i could just use env vars for the keys <niemeyer> rog: If you want to have integration tests in _addition_ to the unit tests, check out goamz <rog> niemeyer: i definitely want both. <niemeyer> rog: The basic trick is that there's a suite of tests that disables itself unless "-i" is passed to the runner * hazmat is excited about unified provider testing * rog is glad about that <niemeyer> rog: That's done by calling c.Skip("<the reason>") in SetUpSuite <rog> niemeyer: ah, i have seen that, but forgotten about it. what does ec2 do about the private keys? <rog> i mean the ec2 package <niemeyer> rog: Check goamz.. it has an authenticator that uses the standard EC2 env keys <rog> niemeyer: cool, so as i thought. makes sense. <niemeyer> rog: Any other changes outside of the checkers that are not related to os.Error? * rog thinks <rog> i don't think so <rog> niemeyer: ^ <niemeyer> rog: Cool, posting the review <niemeyer> rog: Great stuff <rog> niemeyer: cool <niemeyer> rog: Sent <rog> "POP3 checked too recently". dammit, i clicked refresh too early! <niemeyer> rog: WTF? gmail? <rog> niemeyer: yeah <rog> niemeyer: it's ok now - i think it enforces a minute or so's delay <niemeyer> rog: Yeah, I can see that being a good option.. if people check POP3 the same way they press lift buttons, it'd crash gmail quickly <rog> niemeyer: :-) * rog wonders if panic(nil) is the same as runtime.Goexit() <niemeyer> rog: They have pretty different semantics <niemeyer> rog: panic(nil) is just that <rog> niemeyer: yeah they do. but it's not possible to tell which is which in a recover... <rog> niemeyer: i guess we just have to hope that noone calls Goexit inside a PanicMatches checker <niemeyer> rog: What would happen in that case? <rog> niemeyer: i'll just check <niemeyer> rog: It should simply say that the error is nil <niemeyer> rog: Or rather, the recovered value <rog> niemeyer: yeah, but the caller won't get the value <rog> that is returned <niemeyer> rog: Which will likely not match the defined expectation, and the test will fail nicely <rog> it just executes defers <rog> if you're doing it in the same thread, the test will finish <niemeyer> rog: Cool.. no worries <niemeyer> rog: We can think about that latter.. I'm happy to say "Don't do it" for now <rog> niemeyer: yeah, i don't think it's a problem in practice - it's just interesting <niemeyer> rog: Agreed <rog> niemeyer: BTW, what are "fixtures"? <niemeyer> rog: It's a fancy well known term for the setup/teardown in a test suite <rog> niemeyer: ah. not well known to me! <niemeyer> rog: http://en.wikipedia.org/wiki/Test_fixture <rog> should just've googled it! <niemeyer> rog: Sorry, it's certainly fine not to know it.. I just meant to say I wasn't inventing it <rog> niemeyer: sure. i just saw this name used all over the place with no mention in the docs, and it wasn't obvious to me what it referred to... <rog> niemeyer: is it deliberate that gocheck/printer_test.go isn't gofmted ? <rog> [i've never encountered a test before which fails if the test code isn't formatted right :-]) <niemeyer> rog: It is <niemeyer> rog: Precisely because it's testing printing aspects <rog> niemeyer: darn, i just mucked it up by doing gofmt on it then <niemeyer> rog: Just revert it <niemeyer> rog: There may be a wiser way to test it, but let's not mix the issues <rog> sure. it just confused me for a bit... <rog> i'll put a comment in <rog> niemeyer: could we gofmt everything except printTestFunc ? <rog> (in another change, of course) <niemeyer> rog: Yeah, I suspect so.. run the tests and you'll be sure :) <rog> niemeyer: well, i've submitted the changes (not including that one) <niemeyer> rog: It's in <rog> niemeyer: cool <niemeyer> rog: Thanks again * niemeyer => lunch <bloodearnest> heya juju-ers <bloodearnest> I may be missing something obvious, but how do I configure a openstack provider (specifically canonistack)? <bloodearnest> as opposes to an ec2 provider? <_mup_> Bug #888118 was filed: fixes for new error interface <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/888118 > <_mup_> Bug #888119 was filed: fixes for new error interface <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/888119 > <niemeyer> bloodearnest: Hey Simon <niemeyer> bloodearnest: Let me paste you a link, hold on <bloodearnest> niemeyer: thx <niemeyer> bloodearnest: https://pastebin.canonical.com/55366/ <niemeyer> bloodearnest: This is Kapil's email explaining how to setup the internal Canonical openstack provider <niemeyer> (sorry to everybody else, it's just the provider config for Canonical's OpenStack, so not really interesting) <bloodearnest> niemeyer: great, thanks <hazmat> bloodearnest, ostack needs diable, but effectively its just the same ec2 provider with additional config <hazmat> er.. needs the diablo release <hazmat> or newer <bloodearnest> hazmat, diablo is what is in the juju/pkgs ppa for oneiric? <hazmat> bloodearnest, its a question of what version of openstack your running juju against, not the juju version <hazmat> the version in oneiric or the ppas both work fine against the latest openstack release <bloodearnest> hazmat: gotcha <hazmat> which is also in oneiric (latest ostack release) * hazmat lunches <niemeyer> rog: http://paste.ubuntu.com/733258/ <niemeyer> rog: Otherwise we get stuff like this: http://paste.ubuntu.com/733261/ <rog> niemeyer: good point. <rog> niemeyer: shall i push a change? <niemeyer> rog: With the change we have this: http://paste.ubuntu.com/733264/ <niemeyer> rog: Not necessary, if you're fine with it I'll commit <rog> niemeyer: LGTM. we're concerned about the string value, after all. <niemeyer> rog: Right, cool <_mup_> txzookeeper/session-and-conn-fail r65 committed by montgomeryrobert@example.net <_mup_> additional assertion msg on value of test env variable for deb installation of zk <hazmat> niemeyer, btw the wtf ftests seemed to have stalled out a few revs ago <hazmat> 404 vs trunk 411 <niemeyer> hazmat: Will have a look at it <niemeyer> hazmat: I hadn't checked last time you mentioned, sorry <hazmat> niemeyer, no worries, we've all been busy and traveling <_mup_> txzookeeper/trunk r44 committed by montgomeryrobert@example.net <_mup_> - On session expiration, all extant watches recieve an errback. <_mup_> The watches are dead, so there is no purpose in having the session <_mup_> error handler diverting errors for them. <_mup_> - A retry client facade, that transparently retries operations in the <_mup_> face of transient connection errors. <_mup_> - A retry function in the style maybedeferred that can perform this <_mup_> retry functionality for an arbitrary function. <_mup_> - A series of connection failure tests verifying watches are <_mup_> delivered to clients that where disconnected at the time of the <_mup_> watched modification on the server. <_mup_> - version increment to 0.9.0 <hazmat> bcsaller, jimbaker could either of you have a look at lp:~fwereade/juju/clear-ks-meta its been blocking a few other branches in the queue that are approved <bcsaller> hazmat: on it <hazmat> bcsaller, thanks <jimbaker> bcsaller, sounds good, we can have 3 reviews :) * hazmat wonders how much spam mail is for deceased folks #juju 2011-11-10 <hazmat> wtf oracle branding solaris 11 as the first cloud os.. <hazmat> crack marketing.. cloud this, cloud that <hazmat> cloud linux.. http://bellard.org/jslinux/ ;-) <SpamapS> hahaha <hazmat> g'morning <rog> hazmat: yo <hazmat> greetings rog <fwereade> hazmat, should we now be marking bugs "fix committed" rather than "fix released"? <hazmat> fwereade, good question <fwereade> hazmat, heh :) <hazmat> fwereade, i'm unsure.. it probably does make sense, but such usage would mean realigning milestones to releases <fwereade> hazmat, and plausibly tweaking the kanban board <hazmat> fwereade, i was thinking we could have a team meeting today to try and catch up post sprint and that could be a topic of discussion <hazmat> fwereade, i'm already on that one ;-) <fwereade> hazmat, ah, cool :) <hazmat> fwereade, although its more just a new dyanmic readonly lp frontend for juju.. its turning out to be significantly more work than the charm browser <fwereade> hazmat, sounds good, I can be around this evening <fwereade> hazmat, heh :) <hazmat> fwereade, great <hazmat> silly pure rest api * niemeyer waves <niemeyer> I've pointed out I'd be late today earlier, now I noticed I was disconnected.. duh <hazmat> niemeyer, greetings * hazmat ponders puppet <hazmat> fwereade, is 6pm local okay for you re meeting? <fwereade> hazmat, sure <fwereade> hazmat, you marked https://code.launchpad.net/~fwereade/juju/visible-instance-state/+merge/79215 as "needs fixing" a while ago <fwereade> hazmat, did I address your concerns? <hazmat> fwereade, i'll take a look again in a few, i think so.. i backed away from shared state vocabulary * hazmat feels like its been all email and reviews the last few days, the code itch builds <jimbaker> hazmat, fwereade, team meeting sounds like a good idea today * SpamapS imagines a little code-hungry bug inside hazmat chewing on the base of his spine <niemeyer> fwereade: Is visible-instance-state touching the format of the status output? <bloodearnest> hey juju-istas :) <bloodearnest> if I wanted to poke/signal a service (e.g. force a manual reload), whats the best way to to it? config-changed and a dummy config value? <SpamapS> bloodearnest: right now yes, though I'm thinking there needs to be a "refresh everything" command <bloodearnest> SpamapS: kthx. I think a generic "signal" and "handle-signal" or hook (or similar) would be nice <SpamapS> bloodearnest: custom hooks have been discussed as well <bloodearnest> SpamapS: cool. I'll go with config-changed for now. Is there any way to get what the old config value was for a particular field? <SpamapS> bloodearnest: no, I think there's an open bug for that <bloodearnest> SpamapS: kthx <hazmat> bloodearnest, if you want the old value the hook should store it <hazmat> and diff to the new <bloodearnest> hazmat: of course - I will do that :) <SpamapS> https://launchpadlibrarian.net/84857743/buildlog_ubuntu-precise-i386.juju_0.5%2Bbzr413-1juju1%7Eprecise1_FAILEDTOBUILD.txt.gz <SpamapS> looks like juju is broken on precise.. fine on oneiric and natty <hazmat> SpamapS, it looks like a conflict between builtin argparse vs a packaged argparse <hazmat> odd that it only shows up only those on tests, but i guess those tests stuff the python path and launch a process <bcsaller> hazmat: they had updated some strings in the last update of argparse breaking tests as well <jimbaker> bcsaller, doesn't look like the issue here however <jimbaker> (simply some sort of conflict on the python-argparse package for one of our dependent packages, vs the argparse we use anyway) <fwereade> hazmat, meeting time? <hazmat> fwereade, indeed <hazmat> niemeyer, jimbaker, bcsaller, SpamapS ... meeting time.. anyone else? <niemeyer> t+10 <jimbaker> hazmat, niemeyer, sounds good <jimbaker> rog is also waiting, and i'm sure fwereade is interested <hazmat> invites out <bcsaller> its giving me a little trouble connecting, trying again <hazmat> bcsaller, sending a new invite.. <bcsaller> might be faster to just relog, the camera and so on doesn't seem to be working <hazmat> bcsaller, it was sort of like you joined and immediately dropped <hazmat> SpamapS, robbiew invites out to you guys as well if your interested <hazmat> http://www.reviewboard.org/ <SpamapS> hazmat: "I'm not supposed to be here today" ;) <SpamapS> maybe plan the next meeting more than 24 hours in advance? ;) <bcsaller> things are in a surprisingly horrible state of decay here <bcsaller> trying to fix <hazmat> bcsaller, perhaps try a different browser <bcsaller> hazmat: its far worse than that that at this point, anything with GL won't run now, so unity borked. I tried 2d, etc, its not working at all, I have an empty desktop here, but am still trying to connect again <bcsaller> I think its crashing the googletalk plugin too though <bcsaller> everything was fine yesterday, I so don't need this <hazmat> bcsaller, did a reboot help? sounds like a driver problem <bcsaller> no, it didn't <bcsaller> going to see if I can load an older kernel <hazmat> SpamapS, sounds good <niemeyer> 1) The requirement is to put things in the same container <niemeyer> 2) We use relations so the admin doesn't need a different mental model to create slaves <niemeyer> 3) We introduced the idea of juju-info relation so that we don't need the strange idea of promiscuous relations <niemeyer> (copied here so I have in logs.. this is the shortest explanation I could come up with, so want to save.. ;) <fwereade> cheers all, later <hazmat> failure <bcsaller> hazmat: re-invited <hazmat> bcsaller, thanks <niemeyer> hazmat: wtf seems to be fine, btw * niemeyer steps out for a while <nuclearbob> greetings everyone, I'm trying to setup juju using the local/lxc environment, and I'm getting errors when I try to deploy a charm <evan_> nuclearbob: what error are you getting? <nuclearbob> evan_: if I try to deploy the wordpress charm, I get: <nuclearbob> max@WOPR:~$ juju deploy --repository=charms wordpress <nuclearbob> User timeout caused connection failure. <nuclearbob> 2011-11-10 15:20:22,539 ERROR User timeout caused connection failure. <evan_> Do you have the charms on your local machine? <evan_> i.e. I have my charms in a directory called "lucid" so when I deploy - juju deploy --repository . local:lucid/charmname <nuclearbob> I've got them in /home/max/charms <nuclearbob> do I need them in oneiric/charms since I'm on oneiric? <evan_> nuclearbob: juju deploy --repository . local:path/to/charm should work if i'm not mistaken <nuclearbob> evan_: now I'm getting a connection refused, I may have goofed something up, I'll see if I can fix it <evan_> nuclearbob: If the bootstrapping node has not yet completed bootstrapping it could cause this error, ok. <nuclearbob> evan_: I wasn't getting that error before, but I just started after I had been messing with things <nuclearbob> evan_: I can try running the bootstrap again <nuclearbob> evan_: it says I'm already bootstrapped <evan_> nuclearbob: what does it say when you run "juju status" <nuclearbob> evan_: max@WOPR:~$ juju status <nuclearbob> could not connect before timeout <nuclearbob> 2011-11-10 15:37:42,353 ERROR could not connect before timeout <evan_> nuclearbob: Indication the environment needs more time to complete initialization <evan_> nuclearbob: more here https://juju.ubuntu.com/docs/user-tutorial.html <nuclearbob> evan_: thanks, I'll take a look at that <evan_> nuclearbob: you bet <mpl> niemeyer: hi. sorry I couldn't show up so far, it was a crazy week. I'll probably collapse to bed soon, but starting from tomorrow I'll be a lot more available to talk. <nuclearbob> evan_: are you still around? <evan_> nuclearbob: yea, did you get it figured out? <nuclearbob> eavn_: I got the latest version from the ppa, rebooted, ran juju bootstrap (it said it was already bootstrapped) and gave it about a half an hour, but it's still getting timeouts <donspaulding> I sysadmin the servers at my company, around a dozen servers, with heterogenous hardware configs, all running various versions of ubuntu server. What I wanted to build, before I found juju, was a tool that would orchestrate application-level services and their dependencies. Juju seems to fit the bill nicely, except, rather than targeting EC2, or even a private cloud, I'd rather target my own bare-metal servers, with the applicat <donspaulding> I saw where recently the ability to deploy to containers was added, I'm just wondering if there's any explicit push toward supporting that for production deployment? The mailing list message I saw on it seemed slanted towards development/debugging usage. <evan_> nuclearbob: hmmm I am unsure of why it would be doing that. Maybe someone else here would know <nuclearbob> evan_: thanks for pointing me at the tutorial as well, I've got another machine to set it up on, and maybe I can avoid mistakes I might have made on this one <evan_> nuclearbob: no problem. I am fairly new so I'm learning as well. Best of luck to you. Let me know if you figure out the problem #juju 2011-11-11 <niemeyer> Alright good progress.. <niemeyer> But it's way past bed time.. night all <niemeyer> Hallo! <rog> niemeyer: hi! <niemeyer> rog: Yo! <rog> niemeyer: i'm considering putting (at least part of) the ec2 test server under launchpad.net/goamz/ec2/test rather than juju/ec2, because it's bound so tightly to the ec2 protocol. <rog> does that seem reasonable? <hazmat> g'morning <niemeyer> rog: Yeah, depending on how generic it is <niemeyer> rog: Sorry, missed your message earlier <rog> hazmat: morning <niemeyer> hazmat: morning <rog> niemeyer: np <mpl> niemeyer: hi. I'm around if you feel like talking about what you'd like me to start with. <niemeyer> mpl: Hey! <niemeyer> mpl: Cool, so.. <niemeyer> mpl: The first thing I'd recommend is getting comfortable with the concepts around the project <niemeyer> mpl: Trying to use it in the first place, so you understand the overall idea, would be a great start <niemeyer> mpl: Do you have an account on EC2? <mpl> niemeyer: nope. I quickly tried locally with lxc but got some errors. some dude pointed me to some troubles he had locally as well but I haven't had time to investigate more. <mpl> niemeyer: but maybe I can get an account. Do I need to pay if I just want an account and play with juju on it? <niemeyer> mpl: You have, even though it's going to be quite cheap for what you'll have to do <niemeyer> mpl: Like cents <mpl> ok, gonna set up one then <niemeyer> mpl: I recommend playing on EC2 rather than local, because if you're happy with it I'll try to get you involved in developing some features around the EC2 support <niemeyer> mpl: FWIW, if it starts to get expensive because you've spending a good deal of time hacking, I'll be very happy to sponsor your costs <mpl> bah, we're not there yet. besides, at some point I suppose I'll need an EC2 to test some camlistore stuff on there too. <mpl> but thx, good to know. <_mup_> Bug #889125 was filed: Initial implementation of basic ec2 functionality. <juju:In Progress by rogpeppe> < https://launchpad.net/bugs/889125 > <rog> niemeyer: new merge proposal for you. it relies on the previous error fixes though, so i'm not expecting an immediate look. <niemeyer> rog: Cool <niemeyer> rog: Still pumping through.. <niemeyer> rog: Bazaar branch diffing works, and auth works <rog> niemeyer: nice <niemeyer> rog: Now just need to sort the actual rietveld interaction <niemeyer> rog: Hopefully this afternoon I can nail the whole thing down <rog> niemeyer: you gonna branch upload.py or use the stuff from the go tree or do it from scratch? <niemeyer> rog: Did it from scratch.. <rog> niemeyer: probably best <niemeyer> rog: Want to integrate into lbox, so upload.py wasn't suitable <rog> niemeyer: right <niemeyer> rog: The patch stuff in the Go tree was interesting, but ended up being a red herring <niemeyer> rog: So writing a rietveld library, then will glue on lbox <rog> niemeyer: yeah, i saw your CL <niemeyer> But lunch first! :) <hazmat> mpl, if you have any notes from your troubles with the local provider i'd be happy to help debug it <mpl> hazmat: I think you're the one who pointed me to your troubles you had reported. I hadn't even rebooted after I had installed lxc (which is recommended), so that may just be it. as I said, haven't had time to look more into it. but thanks anyway. <jml> hi <jml> I'm trying to deploy a juju formula to lxc locally, and it seems to be hanging on
{'channel': 'juju', 'month': 11}