[00:28] marcoceppi, don't seem on precise [00:28] chris38home_: It might not be available yet then [00:30] is it a way in a bundle to say --to lxc:0 ? [00:47] cjohnston, pong === zz_mwhudson is now known as mwhudson === CyberJacob is now known as CyberJacob|Away === mwhudson is now known as zz_mwhudson === freeflying_away is now known as freeflying === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === JoshStrobl-afk is now known as JoshStrobl === Ursinha is now known as Ursinha-afk === freeflying is now known as freeflying_away === Ursinha-afk is now known as Ursinha [17:33] hello, how do I update code after I deploy with juju ? [17:35] imhotep: Are you referring to Charms that you have created and wishing to update, charms you've deployed with Juju that aren't yours? [17:35] imhotep: which code, the charm or the software? [17:39] marcoceppi: Lemme tell you, setting up vagrant and grabbing the Vagrant box for Ubuntu Server w/ Juju is sooooo much easier than manually setting up my own VM :D [17:40] JoshStrobl: yeah, that's why we pursued that in the first place, we really should promote it more [17:40] marcoceppi: That said, out of curiousity, any reason why LXC is being promoted without using some nice abstraction layer like Docker (since with Docker you can have a Dockerfile that sets everything up as well) [17:41] JoshStrobl: well, because juju talks to LXC directly, there's no need to use an abstraction layer like docker [17:41] juju /is/ docker in this case, only docker + much more [17:41] and the charm is the dockerfile [17:41] JoshStrobl, marcoceppi: software. I believe charm will be frozen since it works (I know there is an upgrade-charm) [17:41] in very /very/ loose terms [17:41] imhotep, upgrade-charm [17:42] basically I want to trigger config-changed to force an update [17:42] imhotep, or for software installed by charm, it should ideally have a config option [17:42] imhotep: it depends on the charm, but some expose a version configuraiton option which allows you to move between versions of the deployed software [17:42] marcoceppi: I suppose but until LXC is really the more promoted method, things are going to be virtualized using Vagrant + VirtualBox, which isn't as "bare-metal" as LXC [17:42] JoshStrobl, because juju and its lxc support pre-date docker by quite a while [17:43] ok it sounds like the one I am using doesn't have that ( I am using the nodejs one) [17:43] JoshStrobl: the vagrant box simply starts an Ubuntu machine with Juju, LXC, and the local provider enabled [17:43] it has a crontab option that updates code on frequent basis (if user sets it) [17:43] marco: I see. [17:43] imhotep: ah, yeah, that doesn't really have a version config, you'll need to use the crontab config [17:44] JoshStrobl: it's the simplist solution to "how do I support LXC on Mac and Windows" [17:44] which means I can't really control right ? crontab would fetch latest code every n seconds/minutes/... [17:45] imhotep: yes, there is work being done on the nodejs charm to make it more responsive to users [17:45] ah cool [17:45] marcoceppi: Of course, since Vagrant is multi-platform, unlike Docker (LXC) which is just now getting Mac support. Not that I have anything against Vagrant, seems to accomplish the same as Docker with some quirks (and Vagrantfile syntax is more complex). [17:46] Just like juju + LXC, Vagrant also pre-dates Docker ;) [17:47] But yea, I was just curious. Figured it never hurts to ask questions, learn along the way and maybe use that knowledge in the future. [17:47] but yeah, we only use the Vagrant box to spin up an Ubuntu machine so you can use juju + LXC [17:47] JoshStrobl, where do you see docker getting mac support? [17:47] uno momento [17:48] http://docs.docker.io/en/latest/installation/mac/ [17:48] It's really recent [17:48] http://blog.docker.io/2014/02/docker-0-8-quality-new-builder-features-btrfs-storage-osx-support/ [17:48] JoshStrobl, that's just downloading a linux a vm to run lxc/docker in [17:49] hazmat: Yes and Vagrant utilizes VirtualBox as well to run lxc, not much different. [17:50] JoshStrobl, yes.. there both using vagrant.. i though you meant some form of native support [17:50] docker notionally has mentioned they'd like to support other containers then lxc [17:50] er.. s/vagrant/virtualbox [17:50] hazmat: Native support in Mac OS X for Linux tech? Haha, don't we all wish? :P [17:51] JoshStrobl, well.. solaris have zones, freebsd have jails.. osx has some support for chroots [17:52] and is based on freebsd userspace.. ie tools like jailkit [17:52] not quite the same though [17:53] hazmat: seems like they'd just have the "providers" as plugins like Vagrant, so you can say run against X container and just abstract an API for provider plugin [17:55] hazmat: hey! question for ya.. IIRC you had recommended to us that for our automated testing we don't destroy the bootstrap node for speed.. we have been doing that, however after making a change to one of our charms we started to get errors with our testing.. it appeared as though we were using a cached charm for deployment or something.. if we killed the bootstrap node and then redeplyed the tests ran with no [17:55] errors. is this expected? [17:55] cjohnston, hmm.. [17:55] cjohnston, so your modifying the charm without incrementing the version? [17:56] hazmat: possibly. I don't know if the version changed or not [17:56] cjohnston, yeah.. juju will internally cache the charm with the given revision [17:56] cjohnston, i filed a bug for this in the api fwiw https://bugs.launchpad.net/juju-core/+bug/1194880 [17:56] hazmat: so if we changed the charm version number it should have worked [17:57] cjohnston, yeah.. you can also deploy with -u which will do it for you [17:57] cool. thanks [17:59] hazmat: I thought -u only worked on local? [18:00] marcoceppi, that's true, but how else would the charm change without a revision increment [18:00] hazmat: juju deploy --repository . local: and not bump the revision file? [18:00] marcoceppi, that's what -u is for [18:01] OH local charm, I thought it only worked on local provider [18:01] I got my locals mixed up [18:02] marcoceppi, no worries.. so digital ocean plugin is looking good.. if your up for testing.. one issue thats preventing release is the precise images there need some massage before use. [18:02] hazmat: I'm always down for testing [18:06] marcoceppi, oh.. it also needs a one-line patch against core to fix a bug in manual provider (https://bugs.launchpad.net/juju-core/+bug/1280432) .. latest is pushed to https://github.com/kapilt/juju-digitalocean [18:06] hazmat: I'll go ahead and compile juju then [18:09] marcoceppi, cool, thanks.. i'll try to plug away at the precise image issues. basically they need an apt-get update/upgrade cycle before juju talks to the machine. [18:09] i've been keeping away from the juju api client so far, but it would be the easiest way to resolve this. [18:14] hazmat: well, shouldn't the manual provider do that? [18:14] marcoceppi, no.. it tries not to perturb machines without cause. [18:14] ah [18:16] marcoceppi, the api for manual provisioning it has some knobs around package install (which i use for my fast lxc provider) but this one is needed a bit earlier in the install cycle. [18:16] mostly the providers rely on cloudinit behavior here === CyberJacob|Away is now known as CyberJacob [19:24] hazmat: is the plugin currently available in pip? [19:24] lazyPower, not yet.. just registered it :-) [19:25] I didn't think so :) just confirming. Following along at home through the readme [19:25] lazyPower, it works welll enough for 13.04/13.10 atm, but till it solid on precise there's not much point to pushing it [19:25] lazyPower, still in pre-release atm [19:25] right. I'm a saucy user [19:25] so i'll clone it and go from there [19:25] lazyPower, well its more about the instances then the client version [19:25] lazyPower, there aren't many charms for non-precise in the official charms. [19:25] oh, you mean their images. Ok [19:26] right [19:26] well its easy enough to pull a precise image, change the series and do a local charm deployment [19:27] lazyPower, for a power user like yourself :-) sure... but goal is end users. [19:28] thats, quite possibly the nicest thing anyone has ever said tome [19:28] marcoceppi: buy this guy a beer for me. [19:28] marcoceppi, they have this awesome beer on tap @ lost dogs.. abraxis :-) [19:29] hazmat: I guess we'll have to go drink up again soon [19:29] We should do a drinkup soonish [20:27] marcoceppi, lazyPower if you have DO support accounts, i'd appreciate an upvote on http://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/5524786-update-ubuntu-12-04-3-images-to-12-0-4-4 [20:27] you have my votes [20:28] hazmat: all 3 of mine just joined the choir [20:58] marcoceppi, lazyPower precise issue fixed in client provider.. and behold.. wordpress charm running on DO http://192.241.155.235/ [20:59] nice! [20:59] huzzah [21:00] pushed latest, and taking a break [21:19] lazyPower: you going to be around in about 10 mins? I think I found the issue with mysql need someone to test [21:19] yep [21:35] marcoceppi, lazyPower confirmed btw that the do provider should work with the dev ppa version of juju 1.17.2 .. but needs --upload-tools on juju docean bootstrap [21:35] hazmat: i'll be on my desktop rig in about 20 minutes and i'll try my hand at bootstrapping [21:37] hazmat: sweet, I'll give it a go after getting the mysql charm patch up [21:50] marcoceppi: you pushing those changes to GH? LP is going offline in 10 minutes. [21:50] lazyPower: already pushed [21:50] branching now [21:50] lazyPower: https://code.launchpad.net/~marcoceppi/charms/precise/mysql/actually-start-mysql/+merge/206597 [21:51] hazmat: I get a missing api creds even though i have a ~/.juju/docean.conf [21:51] marcoceppi, updated the readme.. only env vars at the moment [21:51] oh, hah, cool [21:52] also dropped a release on pypi so the readme should work.. [21:52] hazmat: huh, still not working [21:53] marcoceppi, pastebin? [21:53] hazmat: sure, what would you like? [21:53] marcoceppi, just command and output [21:54] hazmat: http://paste.ubuntu.com/6939820/ [21:55] marcoceppi, hmm.. and values look sane if you do $ env | grep DO_ [21:55] the DO_CLIENT_ID should be the short string [21:57] hazmat: apparently just sourcing the conf wasn't enough, I had to export each line [21:57] now I get this http://paste.ubuntu.com/6939829/ [21:57] did a git pull and install for latest [21:58] marcoceppi, hmm.. argh.. that's probably a delta from the old dop client and the current api it has in github trunk. [21:59] marcoceppi, i'm going to resolve i think my just having a separate do client internal to the plugin, but for now.. resolution is grab a copy of https://github.com/ahmontero/dop and run python setup.py develop in it [21:59] or python setup.py install [22:02] or maybe i should switch out to the other python digital ocean client lib [22:06] fwiw here's some relative timing and usage for bootstrap + add-machine http://pastebin.ubuntu.com/6939864/ [22:06] marcoceppi: success on the mysql charm in HP, checking local and amazon now [22:10] hazmat: bootstrap still fails even with latest dop [22:11] using what's in the git repo [22:12] marcoceppi, same error? [22:12] hazmat: yeah [22:12] * marcoceppi digs a bit [22:12] marcoceppi, you may have to kill the other dop that got installed to /usr/local/lib/python2.7/dist-packages/ [22:12] marcoceppi, surprised your not using virtualenv.. [22:13] hazmat: I still haven't gotten used to virtual env [22:13] I just setup.py install stuff, then blow away /usr/local/... when I get tired of it [22:14] though I might try venv next [22:14] marcoceppi, aha.. sorry i see the issue [22:14] marcoceppi, unset DO_SSH_KEY [22:15] hazmat: ah, I still have to switch to null provider? [22:15] errrr manual provider [22:15] marcoceppi, yes.. whatever env your pointing to must be a null/manual provider [22:17] hazmat: so what should the environments.yaml stanza look like? [22:17] marcoceppi, see readme [22:17] nvm, found the readme [22:17] okay, moving now [22:19] marcoceppi, cool.. also -v gives quite a bit more output then the default.. which is terse [22:19] hazmat: good to know [22:20] hazmat: if bootstrap fails, it should capture that failure and destroy the instance it spun up [22:21] marcoceppi, noted. also if bootstrap fails. you have to manually kill a directory.. boot-$envname in $JUJU_HOME [22:21] * hazmat files bugs [22:21] hazmat: yeah, just found that :) [22:21] hazmat: you tracking bugs on gh? I can start putting those there as I find them [22:22] marcoceppi, yup [22:22] marcoceppi, https://github.com/kapilt/juju-digitalocean/issues/ [22:23] marcoceppi: as soon as launchpad comes back i'll +1 approve the MP. Works on all the providers I have access to. [22:23] great work [22:23] has there been any interest in perl bindings for juju? [22:24] lazyPower: are you verifying that /usr/bin/mysqld is running on each stand up? [22:24] i am [22:26] marcoceppi: standup, validate service is active, add relational charm mediawiki and wordpress [22:26] stokachu, not really.. but if scratches an itch i'd say go for it.. although.. the ideal client technically would be callback or poe based for perl. [22:26] all of the above completed without issue [22:26] lazyPower: oh, nice [22:26] \o/ [22:26] hazmat: ive got a non-blocking library i started [22:26] stokachu, not idiomatic though.. the websocket is async bidi.. [22:26] stokachu, cool [22:27] I mean, it's not really a fix more than it is a huge bandaid until the re-write [22:27] hazmat: https://github.com/battlemidget/perl-juju [22:27] im basically using your api calls as starting point [22:27] stokachu: epic github handle [22:27] but its async [22:27] lazyPower: haha thank you :) [22:28] marcoceppi: I feel like I should go back and add percona tests to some of the charms i've written amulet tests for after our standup on Friday [22:28] hazmat: it uses anyevent which can interface with poe, ev etc [22:28] stokachu, that still looks a bit fishy re the async bits [22:28] lazyPower: really, the mysql charm needs to make sure percona supplies the exact things the interface for mysql implements [22:28] stokachu, your doing sync on top of async loop expecting sync usage [22:28] lazyPower: the burden is on the MySQL charm, not on other charms [22:29] stokachu, afaics.. imagine do 5 calls in a row, and getting responses back in different order [22:29] hazmat: thats what the $done = AnyEvent->condvar handles [22:29] https://github.com/battlemidget/perl-juju/blob/master/lib/Juju/RPC.pm#L83-L94 [22:30] stokachu, yeah.. looking at it.. my perl .. is rusty :-) i generally pull out the camel book [22:30] but its still in early stages so i could be missing soemthing [22:30] so basically condvar handles each session separately [22:31] so even though the calls may be out of order the data responds properly [22:31] so far anyway [22:31] stokachu, cool [22:31] ive still got a lot to learn on event programming apparently [22:32] hazmat: also understand the hybi-13 now [22:32] stokachu, its why goroutines win [22:32] hazmat: yea go does it right [22:32] so much easier [22:32] python gevent does okay.. but baked into the language makes things much nicer [22:32] agreed [22:32] s/gevent/greenle [22:33] i like python tornado [22:33] at least for understanding python events [22:33] stokachu, also nice, but its callback with syntax sugar around yield as coroutine.. py3.4 asyncio is much the same.. tornado is nice though [22:33] gui uses it to proxy intercept augment juju-api [22:34] ah nice [22:34] hazmat: do you think ill get lashes if i blog out the perl bindings at some point [22:34] maybe when it reaches 1.0 [22:35] stokachu, lashes.. no way. code/results == good.. osource .. early and often :-) [22:35] hazmat: hah ok cool [22:36] stokachu, to quote gkh's response back to me on debating/patching kdbus.. "That's why the Linux kernel mailing list very rarely has "idea" discussions, real patches are what matters." [22:36] s/patches/source [22:36] for the same effect [22:36] sweet [22:37] i like that philosophy [22:38] stokachu, so hyb13 vs rfc?... delta == ? [22:38] hazmat: so i think hyb13 == rfc6455 [22:38] i was just confused on those versionings [22:39] stokachu, yeah.. that's basically what i got out of it.. delta being grammatical/syntax on the way to publication afaics. [22:39] the websocket library from go.net is rf6455/hybi13 compliant [22:39] yea i read the diff between them [22:39] and it was just grammatical stuff [22:39] marcoceppi, any progress? [22:40] what i dont get is how to check out what version of the libraries are used within juju [22:40] it just points to p.google.com/go.net/websocket for example [22:41] stokachu, godeps are a state of sadness.. juju-core implements its own dep rev mechanism [22:41] its in dependencies.tsv in root dir of checkout of juju-core [22:41] ah ok that helps [22:44] marcoceppi: http://blog.dasroot.net/juju-plugins-ahoy/ [22:46] lazyPower, so.. how do plugins install in that model.. if they have deps? [22:46] hazmat: we haven't gotten that far with the plan [22:47] the idea originally was to build an API service that works similar to npm that fetches the plugin, and the plugin registers the dependency chain [22:47] but with only 5 plugins to start, we haven't exactly got a need for something that complex [22:47] lazyPower, there are dozens of plugins.. [22:47] not in the juju/plugins repository [22:47] lazyPower, then its not really the plugins repository is it [22:47] depends on your definition of a repository [22:49] One of the ideas I heard was to change it to an organization, and give each plugin their own repository, that way you could warehouse all the dependencies together. But the juju-plugin-plugin aims to solve some of those concerns. [22:49] well a git repo by itself is just a name grab.. the need for more exists, the question is discovery.. minus the npm (cross-language arbitrary install) .. the easiest thing is to just document location via docs page on plugins imo. [22:50] thats cumbersome to update, and invalidate old plugins that are no longer useful as features get expanded in core [22:50] i disagree with it being "the easiest" [22:51] in the first run, yes. that would be insanely easy. When you have 50+ plugins - nope. [22:51] lazyPower, the alternative you proposed was documenting them in that plugin repo.. which amounts to the same issue. [22:51] true, but this is step 1 [22:51] hazmat: if you plugins has deps, package it up like quickstart [22:52] marcoceppi, again discovery is the question [22:52] hazmat: I forsee having plugins in their own github repos soon, and a central registry which will likely have a way to know "how to install plugin" [22:53] hazmat: yay, I deployed wordpress too [22:53] is there a system path that searches for plugins or just ~/.juju-plugins? [22:53] marcoceppi, YIPEE :-) [22:53] stokachu, PATH for juju- prefix commands [22:53] stokachu: plugins work as long as they're in PATH [22:53] stokachu, juju help plugins [22:54] this just adds ~/.juju-plugins to path [22:54] ah ok reading now [22:54] stokachu, only real req on them is --description return one liner .. the rest is per the executable logic. [22:55] gotcha [22:55] stokachu: and have a --help flag [22:55] juj [22:55] oops [22:55] marcoceppi: ok [22:56] marcoceppi, really that's a best practice/suggestion.. not a req afaics [22:56] hazmat: juju help invokes it [22:56] marcoceppi, cool, something new everyday :-) [22:57] marcoceppi, re destroy error, you can rerun [22:57] marcoceppi, i need to introduce a sleep or auto-retry there [23:00] marcoceppi, did you ever find that biz card? [23:00] hazmat: yeah, it's the one you've got [23:00] ack.. bummer.. oh well hopefully more response with working code or via twitter [23:07] hazmat: yeah, could berate over social media [23:09] lazyPower: thanks, merged and should be in the store soon [23:10] awesome, now that i know LP is back online, just commited my approval review [23:10] Oh.. it stored it when they were in maintenance mode. thats nice to know it queues === CyberJacob is now known as CyberJacob|Away