[00:22] curious does it make sense to make a python virtualenv a subordinate to whatever application you want to deploy? [00:23] and only setting the actual relation-* hooks and nothing else so as to have your application rely on that subordinate being available? [00:24] if you deploy the application first it'll fail because the python virtualenv would not be available until after the relation was made [00:27] stokachu: why not make the virtualenv part of the parent charm? are you planning on supporting both styles of deployment? [01:35] lazyPower: i was just thinking in terms of deployment rather than having to do any pre bootstrap to install a virtualenv [01:35] lazyPower: just wanted a clean hooks tree with just python hooks [01:36] i looked at the rails charm to see how thats done but it uses a bootstrap style where it installs rvm then chef to deploy [01:48] yeah [01:48] im just brainstorming on simplifying charm authoring a little bit [01:49] well, i'm under active refactoring of the chef charm template, and am looking at using a charmhelper to handle the installation portion of chef vs this gnarly bash script i'm shipping [01:49] it gets interesting since you can write the charms in any language, however, the install hook needs to install the ruby package before you can use hooks written in ruby [01:49] but ruby gem environments are quite a bit different than python virtualenvs [01:49] right [01:49] understood [01:50] it'd be different if you could ship ruby with the charm [01:50] or perl or python [01:51] i'm fairly certain this has been pioneered and addressed before - but do you really want to bloat the charm with a runtime env that also exists on the system? [01:51] no not really [01:51] thats been my biggest halt on doing something like binstub deployment [01:51] yea definitely [01:51] they *are* more bulletproof though [01:51] it'd be cool if a pre-hook could run where you could install the interpreter of choice [01:51] then use pyenv, rbenv etc [01:51] what i'd like to see is better support for this in charmhelpers [01:52] where you define what you're doing, and it does the heavy lifting in pretext before any actual code is run [01:52] yea that'd be sweet [01:52] and support something more like a declarative model, backing away from the boilerplate approach [01:52] define a charm template to deploy in ruby [01:52] i blame robie for giving me the idea [01:52] i ahven't come up with anything seriously good in that realm yet, but i keep pondering on it.. like /r/showerthoughts [01:53] so dont hate me but i was trying to work through some ideas in perl https://github.com/charmkit/App-CharmKit [01:53] no hate, perl is still a language option covered under "Bring your experience with you" [01:53] which basically autogenerated hooks but packed all required modules in the hooks themselves [01:57] another cool thing was i just importing required modules into the charm namespace [06:06] lazyPower: [06:06] lazyPower: are available at this time? === Murali_ is now known as Murali [09:57] hello guys, I'd like to implement load-balancing mechanisms for my charm. Where can I start? [11:01] HI, i have an issue with my charms dependencies. I have a charm B, which requires charm A to be deployed prior to deploying charm B. How can this be always ensured by juju ? [11:03] Wherever charm B is to be dployed, charm A should get installed automatically, before deploying charm B [11:03] Is there a solution to this ?? [11:05] My chamr B install hook will fail without charm A deployment [11:07] Murali: we don't really have support for that. It sounds like you might want to just merge the two charms into one [11:09] fwereade, for testing leadership election with 1.23-alpha1.1 do I need to a) enable it with JUJU_DEV_FEATURE_FLAG or some such or b) be patient as it's not available in 1.23-alpha1.1 ? [11:11] Murali, couldn't you move the install hook code into the relationship joined with charm a hook? So charm b does nothing until it is joined to charm a, once that happens charm b run the code that was previously in the install hook [11:12] Thanks gnuoy we will try this [11:38] gnuoy: my charm A is subordinate charm. in this case after we add relation b/n A&B, does A gets installed first and then charm B's relation-changed hook called? [11:39] hey guys [11:39] when I deploy a charm [11:39] and then I add units [11:40] Murali, the principle gets installed before the subordinate [11:40] do the unit act "indipendently" or do they share they same resources? [11:40] or better: what do the units share and what do they don't share? [11:42] and another thing... [11:42] I need to use floating ips to access to the machines, but for some charms I don't need them [11:43] gnuoy: the principle install hook code we will move to relation-changed. wont the subordinate get installed first ? [11:45] Murali, the principle is installed first, the subordinate install hook will run afterwards, then the principle <-> subordinate relationship hooks fire [11:45] gnuoy: ok we will try [11:50] Muntaner, the units share the config that has been set by the user (the settings detailed in config.yaml) and they share the settings that the services they are related to have set, and if there is a peer relation they can share data between themselves. [11:51] gnuoy, interesting. So basically, I need an NFS server or similar to share the same contents? [11:51] Muntaner, they are distinct vms so they do not share a filesystem [11:52] thanks gnuoy, what is in your opinion the best way to share the same files? [11:53] and, have you got any suggestions for my floating-ip "issue" ? [11:56] interesting question about file sharing, and tbh, I haven't worked on charms that do that, so I may not be the best person to answer. I see that there is an nfs charm in the charm store and a mount interface (https://jujucharms.com/nfs/) [12:03] gnuoy, have you got any suggestion about the floating ips? [12:03] can I instance a charm without giving it a floating-ip? [12:04] because, right now, I have a small pool (5ish floating ips) and some charms, like mysql, simply don't need it === therealmarv_ is now known as therealmarv [12:05] Muntaner, well it depends on whether you wish to expose all the units to the outside world. Some people use the haproxy charm, assign a floating ip to that, and put the their service behind that [12:06] yes gnuoy, so you suggest to simply detach the floating ips via my OpenStack? [12:06] do juju have something like "juju deploy blabla --dontuseafloatingip" ? [12:08] Muntaner, I don't know what your setup is but in my exeperience units only get a floating ip if they are explicitly given one outside of juju [14:12] gnuoy, pushing the charmhelper resync to next now [14:13] kk [14:15] gnuoy, done [14:15] ta [14:17] gnuoy, do we have a stable branch upgrade test? [14:18] jamespage, upgrading from stable charms to next charms ? [14:18] if so, then yes [14:21] gnuoy, no resyncing the charm-helpers in the stable branches [14:22] jamespage, no. but I could knock one up pretty quick [14:22] gnuoy, let me try :-) [14:22] even better! [14:39] rogpeppe, hello, https://bugs.launchpad.net/loggo/+bug/1256015 this bug is quite annoying, if there's no plan to fix it already, I'm happy to give it a try [14:39] Bug #1256015: It's too hard to enable all log messages [14:40] vds: you might wanna email thumper first [14:40] vds: or reply to the issue [14:41] rogpeppe, I will, thanks. [14:53] gnuoy, is there a nice way to create a new spec? [14:55] jamespage, I tend to just copy an existing one [14:55] gnuoy, ok [15:18] Hi [15:19] aisrael, I don't think Bug #1424069 is fixed fwiw [15:19] Bug #1424069: juju resolve doesn't recognize error state

[15:20] gnuoy: interesting. I'll build from trunk today and see if it still fails for me [15:20] kk === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === blr_ is now known as blr === roadmr is now known as roadmr_afk [20:07] marcoceppi, lazyPower: hey - I have a lint failure on my charm auto test report that I don't get locally [20:07] it's a pyflakes thing, and false failure IMO [20:07] bloodearnest: in meetings, i can take alook when im' out [20:07] lazyPower, ack [20:07] bloodearnest: ~ an hour out - sorry for the delay [20:08] lazyPower, hey, np === roadmr_afk is now known as roadmr === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [23:54] Hi, how to find the version of the charm from the jujucharms.com? [23:54] and is it still true to be able to deploy a charm with specific version such as juju deploy cs:mongodb-25?