[11:20] <bloodearnest> heya folks - am using lxc environment, trying to add a private ppa in my install hook, but apt-cacher-ng is getting in the way. Is there anyway to run  a local lxc env without it?
[11:28] <stokachu> jcastro: http://www.astokes.org/post/2013-07-14-juju-gunicorn-apache-django
[11:28] <stokachu> not sure if you saw that yet, was hoping to get some contributors added to the github project
[11:29] <stokachu> https://github.com/battlemidget/juju-apache-gunicorn-django
[11:30] <stokachu> going to add rabbitmq support soon as well and maybe haproxy
[12:44] <pavelpachkovskij> is there a way I can change config attribute from a hook?
[12:44] <pavelpachkovskij> something like "config-set attr=value"
[13:07] <marcoceppi> pavelpachkovskij: No, you can only manipulate config from the juju cli
[13:08] <marcoceppi> It's not designed to be manipulated from within hooks
[13:08] <pavelpachkovskij> marcoceppy, and if I try to run juju set ... from hook?
[13:09] <pavelpachkovskij> marcoceppi, sorry for typo
[13:09] <marcoceppi> You can try, but you'd have to also include a copy of your ssh private key and ~/.juju/environments.yaml file in order to even start using  the juju cli from the charm.
[13:09] <pavelpachkovskij> I see
[13:10] <marcoceppi> pavelpachkovskij: let me just say, while you can do this, it likely won't be accepted in to the charm store. This is definitely not a good practice
[13:10] <pavelpachkovskij> I understand it
[13:10] <marcoceppi> The impression config has for users is *they* set it, having the charm do it will break that story and preception
[13:10] <pavelpachkovskij> marcoceppi, my problem is that I want to do something like this:
[13:10] <pavelpachkovskij> juju set sample-rails command='rake db:migrate'
[13:11] <pavelpachkovskij> but I can't track for changes if I can't modify this variable from the instance
[13:11] <pavelpachkovskij> though this is a huge workaround there is no other way to run command within application
[13:11] <marcoceppi> pavelpachkovskij: So what you're trying to do is send ad-hoc commands to the charm?
[13:12] <pavelpachkovskij> yes
[13:13] <pavelpachkovskij> It would be nice to have support of ad-hoc commands built into juju itself
[13:13] <pavelpachkovskij> marcoceppi, do you have smth like this in the roadmap?
[13:13] <marcoceppi> pavelpachkovskij: There's a few problems with this particular example. When you run juju set it will run config-changed on all units. Imagine having a deployment at scale (2+ units) they'd all start executing a rake db:migrate, which I can see as being particularly harmful
[13:13] <pavelpachkovskij> I already thought about this
[13:14] <pavelpachkovskij> marcoceppi, and work out a solution with different roles
[13:14] <pavelpachkovskij> marcoceppi, exactly the same way how it is in capistrano
[13:14] <marcoceppi> pavelpachkovskij: There's a mechanism for this kind of one-off command: `juju ssh <charm>/<unit-num> rake db:migrate`
[13:14] <pavelpachkovskij> marcoceppi, this will not work for my purposes
[13:15] <pavelpachkovskij> marcoceppi, issue with 2+ units solves with rack-master and rack-slave nodes in a cluster
[13:15] <pavelpachkovskij> marcoceppi, your solution requires user to now at least root folder
[13:16] <pavelpachkovskij> marcoceppi, maybe it's not the best example, but also I need to update application source code
[13:16] <marcoceppi> pavelpachkovskij: The other thing you can possibly do is trap the previous value of the config, something like `config-get command > .previous-cmd`, check if it's actually changed. The downside to this is, if they set command to be the same exact string again it won't get caught
[13:16] <pavelpachkovskij> marcoceppi, yes, this is the problem I'm trying to solve
[13:17] <pavelpachkovskij> marcoceppi, tracking the change from 'rake db:migrate' to 'rake db:migrate'
[13:17] <pavelpachkovskij> marcoceppi, it just doesn't trigger the hook
[13:17] <marcoceppi> pavelpachkovskij: there's no way currently, unfortunately. Could you describe the entire workflow? Is the command just a one-off or is it part of a bigger process?
[13:18] <pavelpachkovskij> marcoceppi, did you use heroku?
[13:18] <marcoceppi> pavelpachkovskij: I know of it, for the most part
[13:18] <pavelpachkovskij> marcoceppi, I want rack-charm with heroku like behavior
[13:18] <pavelpachkovskij> with support of custom commands and source code update mechanism
[13:19] <pavelpachkovskij> marcoceppi, actually I have a great progress with it, but I don't know how to solve this very problem
[13:19] <pavelpachkovskij> give me a second, I'll push my code to github
[13:20] <marcoceppi> pavelpachkovskij: what you can do instead, is have two config values sections, one that tracks the souce (source-url, source-branch, source-tag, whatever), then one that tracks what commands to run when doing an update (update-cmds). That way the user has described what they want done during updates and you can now trap when there's an update
[13:20] <pavelpachkovskij> https://github.com/Altoros/rack/blob/master/hooks/chef/cookbooks/rack/recipes/config-changed.rb
[13:20] <marcoceppi> ah, yes juju ssh really wouldn't help much here
[13:22] <pavelpachkovskij> marcoceppi, another problem with this approach is that if user change another attribute, command attribute will stay the same and cause another run of command
[13:22] <pavelpachkovskij> marcoceppi, I didn't get your idea with update-cmds
[13:22] <pavelpachkovskij> marcoceppi, can you expand with it?
[13:22] <marcoceppi> pavelpachkovskij: let me write a quick bash example
[13:23] <pavelpachkovskij> marcoceppi, waiting, thanks
[13:46] <marcoceppi> pavelpachkovskij: I'm not sure how well a bash example will translate to chef, but this was my idea: http://paste.ubuntu.com/5877478/
[13:48] <pavelpachkovskij> marcoceppi, yeah... but... there are two issues: 1. Forcing users to write huge configs. 2. It's really hard to fully automate deployment.
[13:48] <pavelpachkovskij> marcoceppi, it's really common case when you want to run custom rake task
[13:48] <marcoceppi> pavelpachkovskij: I don't see how it's anymore difficult than having to run juju set several times to complete tasks
[13:49] <pavelpachkovskij> marcoceppi, if user make a typo, he have to re-run all deployment
[13:50] <marcoceppi> pavelpachkovskij: Could you explain how a typo would force a re-run of deployment?
[13:51] <marcoceppi> I'm not grasping the use case very well
[13:51] <pavelpachkovskij> marcoceppi, forget, this issue is not very important
[13:51] <pavelpachkovskij> marcoceppi, I just don't like this idea
[13:53] <marcoceppi> pavelpachkovskij: We've not has a real strong use case for ad-hoc command running where `juju ssh` wasn't a valid solution. In this case, if you feel strongly about being able to do so, you might want to open a bug with juju-core to start a dialog on how this can be resolved within juju core. Either by allowing the resetting of config values in a hook context, or by adding some new mechanism in juju
[13:53] <pavelpachkovskij> marcoceppi, yep
[13:54] <marcoceppi> Also, juju ssh drops you in as the `ubuntu` user, not directly as root, if that was a previous concern of yours
[13:55] <pavelpachkovskij> marcoceppi, I know that it's ubuntu user, ssh makes it difficult to run simple commands
[13:55] <pavelpachkovskij> you have to ssh to it, go to root folder, su as a deploy user, and only then run your command
[13:55] <pavelpachkovskij> marcoceppi, becomes not simple at all
[13:56] <marcoceppi> pavelpachkovskij: it does, I mean there are other ways around that, like writing convience scrips (imagine just doing `juju ssh 2 run "rake db:migrate"` where run would cd to proper folder, su to user, wrap command or pass to chef solo, etc)
[13:56] <pavelpachkovskij> marcoceppi, I understand that it's easy for devops, but not for a casual developers
[13:58] <pavelpachkovskij> marcoceppi, last example makes sense
[13:58] <marcoceppi> pavelpachkovskij: This might be a better question for juju@lists.ubuntu.com to open a deeper dialog (and the juju-core devs typically read it) for more feedback if you're still looking for alternatives
[13:59] <pavelpachkovskij> marcoceppi, I have to think about this
[14:00] <jcastro> stokachu: I can syndicate your blog post on juju.ubuntu.com
[14:00] <jcastro> stokachu: but feel free to also post it to the list!
[14:00] <stokachu> jcastro: cool, do i need to just tag it with 'juju'?
[14:00] <stokachu> and i can post to the mailing list as well
[14:01] <jcastro> no I have a plugin that sucks it in an I can choose it
[14:01] <stokachu> ah ok
[14:05] <stokachu> jcastro: posted :D
[14:25] <jcastro> negronjl: you're on queue this week!
[14:26] <negronjl> jcastro: Aye :)
[14:26] <negronjl> jcastro:  I should be able to work it early ... I'm in London for two weeks
[14:26] <jcastro> https://bugs.launchpad.net/charms/+bug/1006064
[14:26] <jcastro> this is the only one I care about since we'd like to demo it for oscon
[14:28] <ev> is it possible to specify an instance type for canonistack using gojuju? default-instance-type is now ignored, but bootstrapping with --constraints="mem=6" has no effect. I still get an m1.tiny node.
[14:46] <pavelpachkovskij> marcoceppi, I think using juju ssh 1 run should work for my goals
[14:46] <pavelpachkovskij> marcoceppi, thanks for idea
[14:46] <marcoceppi> pavelpachkovskij: awesome, glad I could help out!
[14:46] <marcoceppi> pavelpachkovskij: just make sure do document it in the readme, etc
[14:46] <marcoceppi> to document*
[14:46] <pavelpachkovskij> marcoceppi, sure
[16:33] <jcastro> hey jamespage
[16:34] <jamespage> hey jcastro
[16:35] <jcastro> I need you to rate the ceph charm before OSCON
[16:35] <jcastro> but don't worry, it's easy, it's like 5 min of work
[16:35] <jcastro> http://manage.jujucharms.com/charms/ceph/precise/qa/edit
[16:36] <jcastro> you need to login
[16:37] <jcastro> adam_g: you need to rate glance and cinder too
[16:38] <jamespage> jcastro,  Access was denied to this resource.
[16:39] <jcastro> are ou logged in?
[16:40] <jcastro> jamespage: ok let's do this
[16:40] <jcastro> https://juju.ubuntu.com/docs/authors-charm-quality.html
[16:40] <jcastro> copy and paste that into an email, the +1 parts
[16:40] <jcastro> and then change things you don't do in the charm to +0
[16:40] <jcastro> and I'll go ahead and enter it in the webform.
[16:41] <jamespage> jcastro, how do I tell which providers it works on?
[16:41] <jcastro> skip that part
[16:41] <jcastro> that's automatic
[16:41] <jcastro> skip all of reliable actually
[16:44] <jcastro> jamespage: got it, thank you sir!
[16:44] <jcastro> adam_g: we just need cinder and glance and then we're all set for OSCON!
[17:42] <jcastro> negronjl: mira, when you do liferay can you rate it?
[17:42] <jcastro> negronjl: also if you can't do it today lmk, I'm on an OSCON schedule so I can whine to someone else to finish it off
[19:20] <jcastro> https://bugs.launchpad.net/juju-core/+bug/1201559
[19:20] <_mup_> Bug #1201559: Prompt the user to generate a key instead of erroring out <juju-core:New> <https://launchpad.net/bugs/1201559>
[19:20] <jcastro> this one's from Maarten
[19:21] <sidnei> hum, is the package in the devel ppa potentially broken? it's not showing up as alternatives
[19:21] <sidnei> $ update-alternatives --config juju
[19:21] <sidnei> There is only one alternative in link group juju: /usr/lib/juju-0.7/bin/juju
[19:21] <sidnei> Nothing to configure.
[19:21] <sidnei> $ apt-cache policy juju-core
[19:21] <sidnei> juju-core:
[19:21] <sidnei>   Installed: 1.11.2-3~1414~precise1
[19:21] <sidnei> $ apt-cache policy juju
[19:21] <sidnei> juju:
[19:21] <sidnei>   Installed: 0.7+bzr628+bzr631~precise1
[19:23] <sidnei> mgz: ^
[19:28] <sidnei> jamespage: maybe you know? ^
[22:05] <sidnei> hazmat: https://code.launchpad.net/~ubuntuone-pqm-team/juju-deployer/refactor/+merge/174877
[22:41] <marcoceppi> hazmat: I've got a question about deployer
[22:42] <sidnei> marcoceppi: ask, maybe i can answer
[22:42] <marcoceppi> If I have two ambiguous relations/interfaces, how would I map that? Can I do "mysql:db": { 'consumes': ['wordpress:db'] } in the relations object?
[22:43] <marcoceppi> The examples show "mysql": { 'consumes': ['wordpress:db'] } but none show if you can map the relation at the top key level
[22:43] <sidnei> marcoceppi: both mysql:db": { 'consumes': ['wordpress:db']} and wordpress:db": { 'consumes': ['mysql:db']} would work
[22:43] <marcoceppi> sidnei: awesome, that makes life a little easier
[22:55] <hazmat> sidnei, marcoceppi the consumes/weights syntax is quite ugly.. .. i'd try..  - ["mysql:db", "wordpress:db"]
[22:55] <hazmat> imo
[22:55] <marcoceppi> hazmat: wait, so I won't have to use weights?
[22:55] <sidnei> yes, there's that too
[22:55] <marcoceppi> I can just have a list of relations?
[22:55] <hazmat> marcoceppi, yeah.. that's legacy format.. i added some  simpler ones..
[22:55] <sidnei> marcoceppi: weights are optional (or should be)
[22:55] <hazmat> sidnei, there not optional in the dict format..
[22:55] <marcoceppi> hazmat: can you expand just ever so slightly on your example?
[22:56]  * hazmat digs up a link
[22:56] <sidnei> hazmat: maybe it's in my branch only? i don't have weights in any of my configs
[22:56] <hazmat> marcoceppi, http://bazaar.launchpad.net/~hazmat/juju-deployer/refactor/view/head:/doc/config.rst#L61
[22:57] <marcoceppi> hazmat: so I should start using yaml instead of json for the deployer cfg?
[22:57] <hazmat> marcoceppi, i do
[22:57] <hazmat> much less typing
[22:57] <hazmat> sidnei, dunno.. perhaps they were optional keys on a dsu sort, but for legacy format, the relations struct was a dict, and it used weight as a sort key
[22:58] <marcoceppi> fantastic. Has this landed in "darwin" branch yet?
[22:58] <marcoceppi> jk, this is the darwin branch
[22:58] <marcoceppi> Okay, moving on. thanks for the clarification!
[22:58] <sidnei> hazmat: im pretty sure i sent an mp to make weight optional, default to None for the sort.
[22:59] <hazmat> sidnei, cool
[22:59] <sidnei> to the legacy deployer that is
[22:59] <hazmat> marcoceppi, hopefully that series distinction goes away this week, going to chat with adam_g post vacation about merging the two
[22:59] <marcoceppi> hazmat: that's make my life easier
[23:00] <sidnei> hazmat: did you fix that issue with things ending up in non-started state not causing deployer to exit non-zero?
[23:01] <hazmat> sidnei, is there a bug for it?  i did fix a minor that deployer wasn't checking state after it did a relation wait
[23:02] <hazmat> so maybe
[23:02] <sidnei> i don't think i filed a bug no, maybe i emailed you
[23:36] <jose> hey guys, when are charms getting reviewed again? mine has been on the queue and wasn't
[23:38] <marcoceppi> jose: the queue is constantly being reviewed, we just rotate who is "on deck" to do reviews
[23:38] <jose> well, I'll wait then
[23:39] <marcoceppi> jose: your postfix charm will definitely get eyes on this week, there's only one charm ahead of you in the queue
[23:39] <marcoceppi> jujucharms.com/review-queue
[23:39]  * jose checks
[23:40] <jose> well, I'll wait then, thanks!