=== defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === thumper is now known as thumper-afk === CyberJacob|Away is now known as CyberJacob === mthaddon` is now known as mthaddon === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === CyberJacob is now known as CyberJacob|Away === rvba` is now known as rvba === jam1 is now known as jam === Guest46086 is now known as jpds [11:20] 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] jcastro: http://www.astokes.org/post/2013-07-14-juju-gunicorn-apache-django [11:28] not sure if you saw that yet, was hoping to get some contributors added to the github project [11:29] https://github.com/battlemidget/juju-apache-gunicorn-django [11:30] going to add rabbitmq support soon as well and maybe haproxy [12:44] is there a way I can change config attribute from a hook? [12:44] something like "config-set attr=value" [13:07] pavelpachkovskij: No, you can only manipulate config from the juju cli [13:08] It's not designed to be manipulated from within hooks [13:08] marcoceppy, and if I try to run juju set ... from hook? [13:09] marcoceppi, sorry for typo [13:09] 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] I see [13:10] 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] I understand it [13:10] The impression config has for users is *they* set it, having the charm do it will break that story and preception [13:10] marcoceppi, my problem is that I want to do something like this: [13:10] juju set sample-rails command='rake db:migrate' [13:11] but I can't track for changes if I can't modify this variable from the instance [13:11] though this is a huge workaround there is no other way to run command within application [13:11] pavelpachkovskij: So what you're trying to do is send ad-hoc commands to the charm? [13:12] yes [13:13] It would be nice to have support of ad-hoc commands built into juju itself [13:13] marcoceppi, do you have smth like this in the roadmap? [13:13] 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] I already thought about this [13:14] marcoceppi, and work out a solution with different roles [13:14] marcoceppi, exactly the same way how it is in capistrano [13:14] pavelpachkovskij: There's a mechanism for this kind of one-off command: `juju ssh / rake db:migrate` [13:14] marcoceppi, this will not work for my purposes [13:15] marcoceppi, issue with 2+ units solves with rack-master and rack-slave nodes in a cluster [13:15] marcoceppi, your solution requires user to now at least root folder [13:16] marcoceppi, maybe it's not the best example, but also I need to update application source code [13:16] 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] marcoceppi, yes, this is the problem I'm trying to solve [13:17] marcoceppi, tracking the change from 'rake db:migrate' to 'rake db:migrate' === cmagina-away is now known as cmagina [13:17] marcoceppi, it just doesn't trigger the hook [13:17] 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] marcoceppi, did you use heroku? [13:18] pavelpachkovskij: I know of it, for the most part [13:18] marcoceppi, I want rack-charm with heroku like behavior [13:18] with support of custom commands and source code update mechanism [13:19] marcoceppi, actually I have a great progress with it, but I don't know how to solve this very problem [13:19] give me a second, I'll push my code to github [13:20] 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] https://github.com/Altoros/rack/blob/master/hooks/chef/cookbooks/rack/recipes/config-changed.rb [13:20] ah, yes juju ssh really wouldn't help much here [13:22] 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] marcoceppi, I didn't get your idea with update-cmds [13:22] marcoceppi, can you expand with it? [13:22] pavelpachkovskij: let me write a quick bash example [13:23] marcoceppi, waiting, thanks [13:46] 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] 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] marcoceppi, it's really common case when you want to run custom rake task [13:48] pavelpachkovskij: I don't see how it's anymore difficult than having to run juju set several times to complete tasks [13:49] marcoceppi, if user make a typo, he have to re-run all deployment [13:50] pavelpachkovskij: Could you explain how a typo would force a re-run of deployment? [13:51] I'm not grasping the use case very well [13:51] marcoceppi, forget, this issue is not very important [13:51] marcoceppi, I just don't like this idea [13:53] 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] marcoceppi, yep [13:54] Also, juju ssh drops you in as the `ubuntu` user, not directly as root, if that was a previous concern of yours [13:55] marcoceppi, I know that it's ubuntu user, ssh makes it difficult to run simple commands [13:55] you have to ssh to it, go to root folder, su as a deploy user, and only then run your command [13:55] marcoceppi, becomes not simple at all [13:56] 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] marcoceppi, I understand that it's easy for devops, but not for a casual developers [13:58] marcoceppi, last example makes sense [13:58] 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] marcoceppi, I have to think about this [14:00] stokachu: I can syndicate your blog post on juju.ubuntu.com [14:00] stokachu: but feel free to also post it to the list! [14:00] jcastro: cool, do i need to just tag it with 'juju'? [14:00] and i can post to the mailing list as well [14:01] no I have a plugin that sucks it in an I can choose it [14:01] ah ok [14:05] jcastro: posted :D [14:25] negronjl: you're on queue this week! [14:26] jcastro: Aye :) [14:26] jcastro: I should be able to work it early ... I'm in London for two weeks [14:26] https://bugs.launchpad.net/charms/+bug/1006064 [14:26] this is the only one I care about since we'd like to demo it for oscon [14:28] 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] marcoceppi, I think using juju ssh 1 run should work for my goals [14:46] marcoceppi, thanks for idea [14:46] pavelpachkovskij: awesome, glad I could help out! [14:46] pavelpachkovskij: just make sure do document it in the readme, etc [14:46] to document* [14:46] marcoceppi, sure === CyberJacob|Away is now known as CyberJacob === defunctzombie_zz is now known as defunctzombie [16:33] hey jamespage [16:34] hey jcastro [16:35] I need you to rate the ceph charm before OSCON [16:35] but don't worry, it's easy, it's like 5 min of work [16:35] http://manage.jujucharms.com/charms/ceph/precise/qa/edit [16:36] you need to login [16:37] adam_g: you need to rate glance and cinder too [16:38] jcastro, Access was denied to this resource. [16:39] are ou logged in? [16:40] jamespage: ok let's do this [16:40] https://juju.ubuntu.com/docs/authors-charm-quality.html [16:40] copy and paste that into an email, the +1 parts [16:40] and then change things you don't do in the charm to +0 [16:40] and I'll go ahead and enter it in the webform. [16:41] jcastro, how do I tell which providers it works on? [16:41] skip that part [16:41] that's automatic [16:41] skip all of reliable actually [16:44] jamespage: got it, thank you sir! [16:44] adam_g: we just need cinder and glance and then we're all set for OSCON! [17:42] negronjl: mira, when you do liferay can you rate it? [17:42] 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 === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie [19:20] https://bugs.launchpad.net/juju-core/+bug/1201559 [19:20] <_mup_> Bug #1201559: Prompt the user to generate a key instead of erroring out [19:20] this one's from Maarten [19:21] hum, is the package in the devel ppa potentially broken? it's not showing up as alternatives [19:21] $ update-alternatives --config juju [19:21] There is only one alternative in link group juju: /usr/lib/juju-0.7/bin/juju [19:21] Nothing to configure. [19:21] $ apt-cache policy juju-core [19:21] juju-core: [19:21] Installed: 1.11.2-3~1414~precise1 [19:21] $ apt-cache policy juju [19:21] juju: [19:21] Installed: 0.7+bzr628+bzr631~precise1 [19:23] mgz: ^ [19:28] jamespage: maybe you know? ^ === cmagina is now known as cmagina-away === elopio_ is now known as elopioo === elopioo is now known as elopio === cmagina-away is now known as cmagina === defunctzombie is now known as defunctzombie_zz === BradCrittenden is now known as bac === cmagina is now known as cmagina-away === defunctzombie_zz is now known as defunctzombie === cmagina-away is now known as cmagina [22:05] hazmat: https://code.launchpad.net/~ubuntuone-pqm-team/juju-deployer/refactor/+merge/174877 [22:41] hazmat: I've got a question about deployer [22:42] marcoceppi: ask, maybe i can answer [22:42] 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] The examples show "mysql": { 'consumes': ['wordpress:db'] } but none show if you can map the relation at the top key level [22:43] marcoceppi: both mysql:db": { 'consumes': ['wordpress:db']} and wordpress:db": { 'consumes': ['mysql:db']} would work [22:43] sidnei: awesome, that makes life a little easier [22:55] sidnei, marcoceppi the consumes/weights syntax is quite ugly.. .. i'd try.. - ["mysql:db", "wordpress:db"] [22:55] imo [22:55] hazmat: wait, so I won't have to use weights? [22:55] yes, there's that too [22:55] I can just have a list of relations? [22:55] marcoceppi, yeah.. that's legacy format.. i added some simpler ones.. [22:55] marcoceppi: weights are optional (or should be) [22:55] sidnei, there not optional in the dict format.. [22:55] hazmat: can you expand just ever so slightly on your example? [22:56] * hazmat digs up a link [22:56] hazmat: maybe it's in my branch only? i don't have weights in any of my configs [22:56] marcoceppi, http://bazaar.launchpad.net/~hazmat/juju-deployer/refactor/view/head:/doc/config.rst#L61 [22:57] hazmat: so I should start using yaml instead of json for the deployer cfg? [22:57] marcoceppi, i do [22:57] much less typing [22:57] 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] fantastic. Has this landed in "darwin" branch yet? [22:58] jk, this is the darwin branch [22:58] Okay, moving on. thanks for the clarification! [22:58] hazmat: im pretty sure i sent an mp to make weight optional, default to None for the sort. [22:59] sidnei, cool [22:59] to the legacy deployer that is [22:59] marcoceppi, hopefully that series distinction goes away this week, going to chat with adam_g post vacation about merging the two [22:59] hazmat: that's make my life easier [23:00] hazmat: did you fix that issue with things ending up in non-started state not causing deployer to exit non-zero? [23:01] sidnei, is there a bug for it? i did fix a minor that deployer wasn't checking state after it did a relation wait === defunctzombie is now known as defunctzombie_zz [23:02] so maybe [23:02] i don't think i filed a bug no, maybe i emailed you === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz [23:36] hey guys, when are charms getting reviewed again? mine has been on the queue and wasn't [23:38] jose: the queue is constantly being reviewed, we just rotate who is "on deck" to do reviews [23:38] well, I'll wait then [23:39] jose: your postfix charm will definitely get eyes on this week, there's only one charm ahead of you in the queue [23:39] jujucharms.com/review-queue [23:39] * jose checks [23:40] well, I'll wait then, thanks! === defunctzombie_zz is now known as defunctzombie