[03:58] <robmoore> m_3: I see in the logs you responded to me but not sure if you were able to look at logstash-agent. It still seems undeployable.
[10:57] <melmoth> hola, with the openstack provider, how can i tell i want my vms to use a give flavor (say m1.large) ?
[10:57] <melmoth> ahh, may be constraint instance-type
[10:59] <melmoth> got it
[10:59] <melmoth> juju deploy etherpad-lite  --constraints  instance-type=m1.large
[11:00] <melmoth> and you end up with /dev/vdb
[11:13] <mgz> melmoth: right.
[11:13] <mgz> you probably want to use the generic constraints instead though
[11:14] <melmoth> like bootstraping with the constraint ?
[11:21] <mgz> melmoth: like, saying cpu=4 mem=8192 (or whichever of those you actually care about instead)
[15:16] <logix812> Anyone else have issues getting the Beta OSX version running?
[15:18] <m_3> logix812: not sure of the status of the osx client... imbrandon? jcastro?
[15:25] <dinopetrone> afternoon all. Attempting to install juju on osx, i ran into a small issue.  Seems like juju is requiring a class in yaml that i don't have
[15:25] <dinopetrone> ImportError: cannot import name CSafeLoader
[15:27] <dinopetrone> >>> yaml.__version__
[15:27] <dinopetrone> '3.10'
[15:28] <dinopetrone> i run into this issue when i try and run the command $ juju bootstrap
[16:11] <mthaddon> gary_poster: howdy - would you be a good person to talk to about the output of "juju status" and what's considered an error (I'm thinking you may have thought about this from your work on the juju GUI)?
[16:22] <gary_poster> mthaddon, hi.  Maybe? :-)  What do you have in mind?
[16:23] <mthaddon> gary_poster: we'd like to parse the output of status for what things could be considered a problem in a juju env - wondered if you have any pointers. Looking for agent-state problems or relation-errors only, I think
[16:24] <gary_poster> mthaddon, I see.  yeah, we categorize everything in a *-error state or with relation errors as units in error requiring attention
[16:26] <mthaddon> gary_poster:  egrep 'relation-errors|agent-state:.*-errors' ?
[16:28] <gary_poster> mthaddon, that sounds about right (though error, not errors).  I'm trying to find the code that actually aggregates this for us...
[16:32] <gary_poster> mthaddon, fwiw, this is our code. http://pastebin.ubuntu.com/5631629/ The only maybe interesting thing is that this seems to say that there might be an "error" state (as opposed to *-error).  I don't recall having seen that, but perhaps it is reasonable.
[16:36] <mthaddon> thx
[16:38] <robmoore> m_3: I see in the logs you responded to me but not sure if you were able to look at logstash-agent. It still seems undeployable.
[16:42] <m_3> robmoore: ack... I saw what was wrong, haven't had a chance to fix it yet
[16:42] <m_3> look at it after current meeting
[16:43] <robmoore> m_3: Thank you!
[17:44] <jcastro> hazmat: either you or mramm go to the docket talk at pycon?
[17:44] <hazmat> jcastro, no.. i have the src though
[17:44] <jcastro> I mean docker, the lxc container "thing".
[17:44] <hazmat> its still using lxc-start/lxc-stop
[17:45] <jcastro> oh so for us it wouldn't be much different then
[17:46] <hazmat> hmm.. i wouldn't say that..
[17:46] <hazmat> i still think warden is probably a better fit out of the box atm
[17:46] <hazmat> ie. its a rest api to lxc container creation (really direct cgroup) over a unix socket
[17:46] <hazmat> used in cloud foundry
[17:46] <hazmat> docker is just a cli atm
[17:47] <jcastro> ok, I was just doublechecking it was on your radar
[17:48] <hazmat> definitely
[17:48] <hazmat> docker being go and lxc related.. definitely on the radar
[17:49] <hazmat> at a minimum it might form a useful basis for at min an lxc wrapper, alternatively we could an remote api layer to it.. either way could be useful.
[18:08] <m_3> robmoore: so it's a problem between the launchpad branches (they're stacked) and the charm store... still debugging
[18:08] <m_3> robmoore: in the mean time, I suggest you deploy from a local repo...
[18:08] <m_3> robmoore: either `bzr branch lp:charms/logstash-agent` or `git clone https://github.com/charms/logstash-agent`
[18:10] <m_3> robmoore: stick that into a local directory like '~/charms/precise' and deploy with `juju deploy --repository ~/charms local:logstash-agent`
[18:10] <m_3> robmoore: hopefully figure out what happened with that branch.  The fix I tried last night didn't work
[18:12] <m_3> robmoore: fyi, it will most likely work once `bzr info lp:charms/logstash-agent` shows no personal (~paulc) branches
[18:19] <robmoore> m_3: I appreciate the instructions. I'll give it a shot and let you know how it goes.
[18:20] <m_3> robmoore: sorry man... this problem's been here a while... haven't had chance to clean it up
[18:22] <m_3> btw, all ~charmers:
[18:22] <m_3> to promulgate (promote a branch to be an official charm in the store)
[18:22] <m_3> http://paste.ubuntu.com/5631671/
[18:22] <m_3> the `bzr init` step is critical
[18:23] <m_3> after you've promulgated, the `bzr info lp:charms/<charm-name>` should show no personal branches
[18:23] <m_3> i.e., be unstacked
[18:24] <m_3> I'll get that out to the list as well
[18:28] <SpamapS> m_3: quite easy to put those steps into promulgate...
[18:29] <m_3> SpamapS: yeah, good point
[18:29] <m_3> SpamapS: I just learned about the init step last week.  I'd always just cloned a fresh version from lp:~charmers before promulgating
[18:31] <SpamapS> m_3: seems logical to me. :-P
[18:31] <SpamapS> m_3: anyway, its bzr/lp weirdness that no charmer should need to know about :)
[18:32] <m_3> SpamapS: agree
[18:34] <m_3> robmoore: ok, logstash-agent's fixed... should depoy fine from the store now
[18:35] <robmoore> m_3: Excellent! Thanks for your help.
[18:36] <m_3> robmoore: np... hazmat figured it out... more subtle bug than just branch stacking
[22:28] <hazmat> jcastro, incidentally just pushed cs:~hazmat/precise/docker if you want to play with it