[00:17] * Makyo is away: EoD [00:36] oh that's annoying [00:36] https://github.com/kapilt/juju-digitalocean requires manual deployment of VMs before you can put services on them [00:36] doesn't that kinda defeat the purpose? [00:37] bodie_: that is why it's called the 'manual' provider :) [00:38] *mutters* [00:39] bodie_: heh, yea that's the advantage of using full providers [00:39] call it a forcing function [00:40] digitalocean just got $37M in funding.. maybe we should think about enhancing juju's interface with 'em at some point ;) they're trying to take on AWS [00:41] really hits the price/performance sweet spot with all the extra fluff removed [00:42] not that EC2 and S3 are fluff... but for a lot of people, the bells and whistles just complicate things [00:42] just thinking out loud here :) [00:43] I'm sure others have pondered and sent an email or two :) === whit_ is now known as whit === Kyle- is now known as Eliz [00:56] bodie_: the ball is in their court, they need to provide an API [00:56] and join the CPC program [03:48] lazyPower: hey! around? [03:48] jose: I think he's off for the evening [03:49] marcoceppi: oh, I had a question (as he was the last to review the mailman charm) [03:49] I'm about to do a push and wanted to see if someone could test it (local provider has some problems as you know) [03:50] jose: I can try [03:50] sure, I should push it in ~3m [03:53] marcoceppi: mind trying the charm? config-changed was giving an error before, should be fixed now [03:53] jose: linky link? [03:53] https://bugs.launchpad.net/charms/+bug/1199052 and https://code.launchpad.net/~jose/charms/precise/mailman/trunk [03:53] <_mup_> Bug #1199052: New charm: mailman [03:53] lp:~jose/charms/precise/mailman/trunk [04:09] marcoceppi: any blockers found? [04:09] jose: http://paste.ubuntu.com/7088242/ [04:10] marcoceppi: you know a way of using spot instances with juju? like, manually? I *may* be able to afford a couple to test [04:11] jose: the manual provider can do that [04:11] jose: what's wrong with local provider? [04:11] last time I tried using there was a bug on LXC which prevented me from deploying [04:11] I'm going to try again [04:12] ERROR cannot find network interface "lxcbr0": net: no such interface // ERROR failure setting config: cannot find address of network-bridge: "lxcbr0" // ERROR cannot find address of network-bridge: "lxcbr0" [04:12] marcoceppi: ^ [04:13] jose: sudo apt-get purge lxc juju-local [04:13] sudo apt-get install juju-local [04:13] see if that creates the lxcbro [04:13] * jose does [04:15] ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju deploy cs:trusty/ubuntu [04:15] ERROR charm not found: cs:trusty/ubuntu [04:15] Y NO TRUSTY CHARM!!! [04:16] because we no promulgate trusty charms yet [04:17] Y U KEEP CHRM SECRETT [04:17] marcoceppi: oh, do you have a link to those trusty tests docs you mentioned? [04:18] davecheney: because charms have no tests! [04:18] jose: which trusty tests docs? [04:18] you mentioned having some docs about writing the tests for charms to be on trusty [04:18] marcoceppi: ubuntu charm is awesome, it is the chuck norris of charms [04:19] it doesn't need tests [04:19] davecheney: you bring up a good point though, we need to start testing trusty like tomorrow [04:19] marcoceppi: i need to test it like months ago :) [04:20] davecheney: I can push the ubuntu charm to trusty if you'd like [04:20] it's obviously going to work [04:23] davecheney: cs:trusty/ubuntu exists now, may take a few mins for the store to find it [04:23] davecheney: nope, it found it https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/ubuntu [04:24] marcoceppi: juju first downloads the precise image before deploying, right? [04:24] jose: yes, the precise clodu iamge [04:24] then it'll take a good while [04:25] I better go grab a cup of coffee [04:29] marcoceppi: w00000000t [04:29] thanks [04:30] i can use a local charm [04:30] but the whole test is that we can talk to thet charm store via a proxy [04:30] so local charms defeate the purpose [04:30] davecheney: I want to enable you FOR GREATNESSS [04:30] thank you sir [04:30] do you have a suitable imgur for this ? [04:34] http://i.imgur.com/1ida17K.jpg [04:34] not relaly [04:34] awesome though :) [04:34] though I've been abusing this one recently, davecheney, http://i.imgur.com/9EqJvVX.gif [04:42] marcoceppi: hey, it says 'instance-state: missing' [04:43] jose: that's progress, what does ~/.juju/local/log/machine-0.log have for contents? [04:43] hmm, /me checks [04:44] marcoceppi: http://paste.ubuntu.com/7088329/ [04:45] jose: it looks like it's still progressing [04:45] give it a few more mins checking juju status occasionally [04:45] sure, thanks [04:46] jose: what does sudo lxc-ls --fancy show? [04:46] state: running, gives me an ip address [04:47] marcoceppi: mind a PM on another topic? [04:47] sure [04:56] marcoceppi: I cannot seem to find the error on config-changed... Everything looks sane to me [04:57] jose: let me get you the log [04:59] http://paste.ubuntu.com/7088378/ jose [05:00] night all [05:03] let's see [05:12] oh, I'm going to check that === zchander__ is now known as zchander [07:05] is there any way to stop juju from tearing down the instance when it fails to bootstrap, so I can investigate why? [07:06] I'm seeing: [07:06] Bootstrapping Juju machine agent [07:06] 2014-03-14 06:51:09 ERROR juju.provider.common bootstrap.go:123 bootstrap failed: rc: 1 [08:06] I don't suppose there is a daily package built of HEAD somewhere? [08:09] https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily no longer seems to exist === erkules_ is now known as erkules [09:14] Hey guys, where is the Charm Bundle lesson? [09:17] marcoceppi: says you'll be on of the speakers, where's the stream? [09:18] hmm, maybe my Google Calendar just got messed up or something and is displaying the wrong time to me [09:20] oh yea, 1400 EST on Friday (just looked at the email). Good job Google, waking me up for no reason :\ [09:21] * JoshStrobl goes back to bed [12:20] hazmat: got an issue with python-websocket-client, which python-jujuclient uses. [12:21] hazmat: I need to shift the dependency to python-websocket, since we have a dupe. This involves effectively bumping the version in Trusty from 0.11.0-0ubuntu1 to 0.12.0-1 [12:21] hazmat: do you see any problems with that? [12:21] jamespage: ^^ [12:21] rbasak, going to give it a quick test as well [12:21] I use deployer alot [12:24] rbasak, should be fine.. i'll double check re changes [12:24] rbasak, yup that's fine.. i use that version already [12:25] via pip/virtualenv installs [12:26] hazmat: thanks! === BradCrittenden is now known as bac [13:16] mbruzek, lazyPower, those errors you got with the subordinates and the bundles last night, you got those in the GUI right? [13:17] jcastro, I was using the command line. I did not see any errors, I only saw 3 charms deployed from that bundle. [13:18] I am sure there were errors that prevented that from deploying, but I didn't dig into it. [13:18] jcastro: the gui was watching the bundle and returned the error to the user [13:18] jcastro: but the error came from lower down the stack [13:19] mbruzek, can you see if you have the bundles you tried in your history? I'd like to dig today [13:21] jcastro, http://pastebin.ubuntu.com/7090108/ [13:21] I destroyed the environment at the EOD but that is how I ran it. [13:21] ah got it [13:21] I mistakingly put in the "complex", but chuck caught that and I removed it [13:21] pushed a new version, trying it now [13:22] Out of that list of charms, I only saw juju-gui, kibana, and haproxy deployed iirc [13:22] yeah, rails takes like 10 minutes at least [13:22] it does all this ... rails stuff ... [13:22] pull the universe from git, etc. [13:22] I am trying it now [13:23] OK [13:28] Hi all... Got another (weird) error. Just reinstalled my MaaS and whenI want to bootstrap my Juju, I get iscsi errors [13:50] * zchander seems baffled.... Somehow some ephemerals were installed twice...... :( [13:51] jcastro: i've tried it on several installations. the units were never coming online [13:51] that error failed the entire bundle deployment. i'm not saying its not my env being the culprit though [13:51] yeah rick is investigating [13:51] no I reproduced, and so did mbruzek just now [13:51] ah ok [13:51] but this exact bundle was working a few days ago, so clearly something changed [13:52] lazyPower, I am worrying about the sample app in the rails charm though [13:52] jcastro, that pastebin was from yesterday [13:52] mbruzek, yeah the exact same thing happened to me [13:52] just now [13:52] Ok [13:55] jcastro: ok let me wrap this subordinate I am hacking on and I'll pull that sample rails app and see how it goes [13:55] I am +1 if you want to replace pavel's app with another hello-world style app [13:56] actually [13:56] let me deploy pavels app on the rails charm now. it wont take long [13:56] jcastro: [E 140314 09:52:59 utils:72] error deploying the bundle │······················· [13:56] [E 140314 09:52:59 utils:73] error type: │······················· [13:56] [E 140314 09:52:59 utils:79] error message: subordinate service must be deployed without units [13:57] how did it let me create that in the first place? [13:58] jcastro: wow, this error was mentioned in our irc back in July [13:59] well, I prefer known to unknown. :) [13:59] http://irclogs.ubuntu.com/2013/07/24/%23juju-gui.txt line 73 [14:00] ok so worse case, remove the subs [14:00] but then the bundle is kind of less useful [14:00] jcastro: pulling num_units and going to try it out again [14:00] jcastro: I think just removing the unit specifier will work, but testing [14:01] ok [14:01] * Makyo is back (gone 13:44:06) [14:03] rick_h_, the django bundle has the same errrors [14:03] so hopefully that's the badger [14:03] jcastro: in looking at the source code here, num_units isn't valid param for subordinates. Did you export this? I thought we didn't export that value any more [14:03] I exported it [14:03] I've done no manual mangling other than renaming the envExport [14:04] jcastro: will file a bug on that then. We shouldn't export that setting [14:04] ok so I should remove that from the bundle and try again? [14:04] rick_h_, remove all of the num_units right? [14:05] hmm, same error [14:05] jcastro: yea it's what I did to try out but failed again [14:05] * jcastro stands by [14:07] jcastro: which are sub's in here? [14:08] logstash agent [14:08] nrpe? [14:08] maybe nrpe? [14:08] I don't remember, I made the bundle like 3 weeks ago, heh [14:08] iirc I thought subs would be mentioned in the file [14:09] rick_h_: confirmed nrpe and logstash-agent are the subs [14:10] lazyPower: k, trying another take [14:11] jcastro: ok, change the num_units to 0 [14:11] on the subs [14:12] jcastro: don't ask me why, but it's what the code says and it's deployed the rest of the services. So run with me here :) [14:12] lazyPower: ^ [14:12] for the django one [14:12] as well I'd imagine [14:12] neither nrpe or logstash-agent have num_units mentioned [14:13] do you think it's assuming one? so explicitly add it and declare 0? [14:13] rick_h_: http://i.imgur.com/00Ugaft.gif [14:13] jcastro: yes, it seems to assume 1 and then error. I set it to 0 and it's working [14:14] man, that's an awesome bug [14:14] jcastro: pretty much [14:16] jcastro: k, all done. rails failed on install hook error but the rest went out [14:16] the sample app one that is [14:17] jcastro: I take issue with the way the rails bundle is structured [14:17] marcoceppi, ok [14:17] Since it's a "framework" charm it's still to just deploy it [14:17] fire away [14:18] We should instead model some rails software in the bundle instead [14:18] like rails/ [14:18] since bundles should model workloads [14:18] find popular rails apps and build bundles for them in the rails name space [14:18] marcoceppi: I suggested stringer as a possible replacement. [14:18] another one would be spree, the ecommerce solution. [14:19] another issue with the charm in general, but it's not your fault jcastro, is a lot of times it needs post-deployment commands to work properly [14:19] yes, I had to mention that [14:19] (db:migrate, asset"precompiile, etc) [14:19] jcastro: http://stackoverflow.com/a/487407/196832 [14:19] basically, django and rails need things like, a config.yaml for where the code lives, etc. [14:20] marcoceppi: since we cleared the security groups lastnight I haven't been able to reach anything i've deployed on HPCloud - is there a stray setting aside from the .jenv i need to wipe? [14:21] wait, i can reach it via ssh, but not port80 post being exposed [14:21] * lazyPower wat's [14:21] lazyPower: did you have anything deployed before the wipe? [14:21] i did :( [14:21] yeah, they're inaccessible [14:21] i had a bootstrap node chillin in there that I manually wiped from the console. [14:22] best to destroy environment and move on [14:22] i just rebootstrapped [14:22] * lazyPower wipes and tries again [14:30] marcoceppi, ok how about example-single and example-scalable? [14:30] to make it explicit that it's a hello world for you to customize? [14:30] jcastro: such compromise [14:30] jcastro: much synergy [14:31] rick_h_, blamo, worked first time [14:31] ok going to do what marco wants, push, and then we'll see about the example app [14:31] going to fix/push django too [14:32] so, probably needs to be on deployer than [14:32] jcastro: woot thanks for the help in debugging. I've got a card for us to find the right place to file the bug. [14:32] a bug* === hatch__ is now known as hatch [14:58] hazmat: about python-jujuclient again. test_jujuclient.py is in bzr, but not in the PyPI distribution, so I can't easily run the test suite as part of a package build (MIR requirement). [14:58] hazmat: I just dealt with exactly this problem in websocket-client by plucking out the test suite in a packaging patch. [14:59] hazmat: please can you add it to setup.py? [15:01] rbasak, sure [15:01] rbasak, i hadn't realized this was going into main [15:01] rbasak, i've got meetings for the next 2hrs but will come back to it today [15:02] hazmat: np. Unless you do a PyPI release and I update packaging I'll have to do a distro patch anyway. [15:02] hazmat: it's going into main because juju-quickstart needs it. [15:03] hazmat: "Seriously Alpha. Works now, but API *will* change." alarms me a little for main inclusion. [15:04] * rbasak takes a break to unwind his stack [15:06] rbasak, yeah.. i should take that out, it was commentary from the first release against the api, but in truth it has been pretty stable to date [15:07] hazmat: thanks. I will quote that for the MIR :) [15:47] fainally, I could not run Discourse.org by juju :( [15:48] My problem is repored here: http://discourse.ubuntu.com/t/how-to-install-juju-manually-cloudimg-tar-gz-where-should-it-be-extracted/1548 [15:49] if you can help, please help [15:56] lazyPower: ^ [15:58] onrea: ack, hang on i'm going to tap one of the more knowledgeable people [16:00] onrea: put them in /var/cache/lxc/cloud-precise but don't extract them [16:00] :) [16:00] both of them? [16:00] onrea: yes [16:01] w8 [16:03] marcoceppi: PLease check the instruction for any missing/wrong step: [16:03] 1. sudo juju destroy-environment -y local [16:03] 2. juju init && juju switch local [16:03] 3. sudo chown -R emzi.emzi ~/.juju ~/.ssh === BradCrittenden is now known as ba === ba is now known as bac [16:03] 4. juju bootstrap [16:04] onrea: once you've dstroyed you don't need to re-init [16:04] 5. juju deploy --repository=$HOME/charms local:discourse [16:04] 6. juju deploy postgresql [16:04] 7. juju add-relation discourse postgresql:db-admin [16:04] 8. juju expose discourse [16:04] 9. juju status [16:04] 10. watch juju status [16:04] lazyPower: ok [16:05] onrea: otherwise that set of instructions loks fine, i don't see anything crazy [16:06] Ok, thanks @lazyPower, marcoceppi. I'm going to rock discourse with juju... === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [16:33] ERROR cannot use 37017 as state port, already in use [16:33] anyone know how to fix this one with the local provider? [16:34] I've blown away local.jenv and the environment/local directory [16:40] jcastro: sudo initctl list | grep juju [16:42] ok I see stuff [16:42] do I stop/restart it? [16:43] jcastro: yea, I just ps aux | grep mongo and kill the mongodb instance running [16:43] jcastro: sudo stop each of those [16:44] then rm -f /etc/init/juju-* [17:37] ==> unit-jenkins-slave-0.log <== [17:37] 2014-03-14 17:37:43 ERROR juju runner.go:220 worker: exited "upgrader": cannot read tools metadata in tools directory: open /home/jorge/.juju/local/tools/1.17.4.1-prec [17:37] ise-amd64/downloaded-tools.txt: no such file or directory [17:38] I've not run into this before [17:39] jcastro: this is something that happened during the 1.17.4 update - if you ln -s the saucy tools to precie it goes awy [17:39] and its only log spam - it doesn't appear to have any effect over deployments in my testing. [17:40] s/precie/precise [17:40] I don't have saucy or precise tools [17:40] are you running trusty? [17:40] yeah [17:40] probably trusty-tools then [17:40] same principal [17:40] but ymmv - i dont know if there was a specific difference between the series. [17:41] ah [17:41] I don't seem to have /releases/juju-1.17.4.1-trusty-amd64.tgz [17:41] can I sync-tools post-bootstrap? [17:41] good question [17:42] * jcastro tries it [17:42] i think so [17:42] juju sync-tools is referenced in this answer [17:42] http://askubuntu.com/questions/285395/how-can-i-copy-juju-tools-for-use-in-my-deployment [17:43] it didn't work, but the service is up [17:43] so Good Enough [17:44] * lazyPower nods [17:44] the log spam is annoying, i'll file a bug [17:45] well, the tools are also missing [17:45] that might be a problem, heh [17:45] yikes! [17:45] sinzui: anything going on with streams/tools that you are aware of? [17:46] Nothing yet. [17:46] brb [17:47] lazyPower, It is stable right now. When will ask for an update to get 1.17.5 when I see the arm64 and ppc packages in ports [17:53] sinzui: ack, thank you for looking into this for us [17:58] Juju Charm School on Bundles in 2 minutes! [17:58] https://plus.google.com/hangouts/_/hoaevent/AP36tYdbEgmEEjOzBoN2_eYNDyWicF98hHYXAdD2H92SaNCpwqY1DA?authuser=0&hl=en [17:58] there's the URL [17:58] http://youtu.be/eYpnQI6GZTA if you just want to follow along [18:01] Will the Youtube stream automatically start playing the video once it's being broadcasted? [18:01] JoshStrobl: yes, should start in a few mins [18:01] cool [18:01] JoshStrobl: rather, it should be running now [18:01] may need to refresh [18:02] yep! [18:02] refreshed and it's buffering [18:02] well, it's loading as in waiting...or something like that. no way it's buffering on my connection [18:03] JoshStrobl: its live for me - still having issues? [18:04] not any more. just ended up loading firefox and it was fine [18:04] good job Chrome, good job... [18:04] * lazyPower golf claps for chrome [18:05] Feel free to ask questions anyone watching, and I'll relay them in to the video! [18:11] aanndd this is why I use nano in the terminal :P === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [18:16] any questions so far? [18:17] jcastro: the ingest runs every 15 minutes, so worst case is you just miss and it takes two cycles, 30 minutes [18:21] No questions from me :( [18:21] * :) [18:23] jcastro: you should be able to drag directly from the rails charm to that mongos instance in the middle. [18:24] jcastro: crazy? that was every day in a prior life :) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [19:07] hey lazyPower, I changed my charm from Incomplete to Fix Committed again barring a response from you (regarding my response to you): https://bugs.launchpad.net/bugs/1278369 . Waiting a while and noticed there wasn't any reply on it when it hadn't been changed, so I went ahead and changed it. [19:07] <_mup_> Bug #1278369: Charm Needed: metis [19:08] JoshStrobl: thanks! i reached out and didn't receive an email response - so without it being in teh queue and no 1:1 from you it was pending re-entry into the queue [19:08] i should be able to get you the +1 today before I EOD [19:08] lazyPower: Ah, thought that since ~charmers were subscribed that maybe it'd notify others, guess not. [19:09] yeah - with me not being a charmer yet (emailing the list today to petiton for membership) - i don't get those notifications yet. [19:10] lazyPower: I changed to Fix Committed since it was more relevant to my actual post (I had changed to Fix Committed prior to you setting it as Incomplete since like 99% of everything marcoceppi talked about was resolved). Not necessarily looking for the +1 (although that'd be nice), more like "hey, the stuff you said wasn't resolved actually was, here is a long post about it". [19:14] If you have any questions and feel it'd be more appropriate to discuss on IRC rather than mailing list, I'll obviously be around...probably for 5 or so more hours. [19:19] JoshStrobl: ack. I'll ping you shortly [19:19] wrapping up some expedited requests now [19:28] lazyPower: hey, if you're around and have a minute, looks like I fixed the mailman charm [19:28] jose: awesome :) did you move the status of your ticket to fix committed? [19:29] lazyPower: well, to new, but moved it [19:29] ack. as long as its in the revq i'll get to it before my shift ends for teh week [19:36] JoshStrobl: ok moving on to metis - incoming review [19:37] lazyPower: Thanks bud. [19:45] JoshStrobl: without cryptograhic verification of file signatures I cannot pass the charm, its a hard stopper. I respect your concern of continuous delivery though [19:45] lazyPower: Any suggests? [19:45] *suggestions [19:45] My thought would be to use git itself as the delivery mechanism, since git validates the file signatures cryptographically [19:46] you can use tags in the same vein as you would be zip packages [19:46] then you just deliver from your github repository using the tag, and make tag the configuration option for deployment [19:46] or hash, or whatever. This satisfies a default stable release and allows for upstream deployment as well so you're not updating your charm over and over to get the new releases in [19:48] Gonna be honest, didn't even think about using git. Feel free to mark as Incomplete barring fix, I'll implement using git as the delivery mechanism when I get the chance and will change it to Fix Committed when it's done. [19:48] *git for delivery [19:48] JoshStrobl: if you want any help/pointers ping me and I'll hop on a hangout with you [19:48] Cool, thanks! [19:48] and thank you for being patient during the review process, i know this has quite a bit of back and forth. I want to see this land in the charm store soon after seeing how much effort you've put into it [19:49] lazyPower: Thanks for your kind words and the tip on using git (makes sense since the code is on GitHub anyways) =) [19:57] * lazyPower hat tips [19:57] jose: incoming mailman review [19:57] lazyPower: thanks! === hatch__ is now known as hatch [20:49] jose: correct me if i'm wrong, but i'm seeing the same failure [20:49] was this corrected on the postfix charm? [20:49] lazyPower: hmm? let me double check [20:49] as that may be why i'm not seeing the fix show up [20:49] no, it was corrected on the mailman charm [20:50] let me double check just in case [20:50] ack [20:50] hmm, no, it was corrected on the 7th revision [20:50] which is on LP atm [20:51] I did a successful deploy with it on my local env yesterday [20:51] I'm sitting on revision 5 [20:51] and it just updated [20:51] wat... [20:51] i'm slippin [20:51] ok let me upgrade the charm and start over - ty for confirming [20:52] :P np [20:54] good news! it passed the config-changed hook blocker [20:54] moving on === nszceta_ is now known as nszceta === hatch__ is now known as hatch [21:18] ok last call for anyone with last minute charm submissions before i EOD [21:18] you've got 15 minutes [21:36] * lazyPower EOD's [21:37] jose: ping me when you've got those changes and i'll re-review for ya later tonight and get your +1 on record [21:37] awesome, thanks! [21:37] JoshStrobl: not sure if you're still hacking away, but same goes for you. === lazyPower changed the topic of #juju to: Welcome!! Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP [21:45] marcoceppi: hi -- amulet is supposed to intercept calls to deploy the "current" charm, right? We are seeing that isn't happening as we expect. Known issue? [21:46] dpb1: how are you executing the test with charm test or directly? [21:46] if directly you'll need to see this Ask Ubuntu question [21:47] hmmm. [21:47] charm test? [21:47] we are using juju test [21:47] dpb1: that's one in the same [21:48] reading in a deployer config file with 'branch: lp:~landscape-charm/trunk' [21:48] juju test == charm test; are you launching juju test from the charm_dir? [21:48] yes [21:48] dpb1: OH [21:48] that's why [21:48] :( [21:48] it only intercepts on d.add() [21:48] dpb1: file a bug and I'll see what I can do [21:49] OK [21:50] marcoceppi: there are other problems with the config-based deployment that I haven't filed yet. But this one is more tricky for me to work around. [21:51] marcoceppi: what do you whink about this other idea, [21:51] marcoceppi: when creating a deployment, like [21:51] d = amulet.Deployment(sentries=False) [21:51] marcoceppi: pass it an existing directory where I have already checked out all the branches I want deployer to use [21:52] it's like pre-creating precise/, and then calling deployer [21:52] it will see the charms are already there and not update them, nor check them out again [21:53] so, I would call it like [21:54]