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