[00:00] * SpamapS EOD's [02:38] SpamapS: re: rabbitmq. no, none of those ~openstack-ubuntu-testing charms are relevant to anything outside of that jenkins lab [03:36] <_mup_> juju/unit-rel-lifecycle-start-invoker r535 committed by jim.baker@canonical.com [03:36] <_mup_> Merged trunk [03:39] <_mup_> juju/unit-rel-lifecycle-start-invoker r536 committed by jim.baker@canonical.com [03:39] <_mup_> Addressed review points [03:50] adam_g, i just committed the fix for working with relation ids from relation hooks to trunk. SpamapS, this is a trivial one-liner and imho should be included asap in the juju distro [03:51] along the lines of other recent fixes we have had === jkyle_ is now known as jkyle [04:51] jimbaker: cool. if theres an SRU bug somewhere, i can verify. or let me know, and ill file one === koolhead11|afk is now known as koolhead17 === almaisan-away is now known as al-maisan === koolhead17 is now known as koolhead17|afk === koolhead17|afk is now known as koolhead17 === al-maisan is now known as almaisan-away === daker__ is now known as daker === TheMue_ is now known as TheMue === TheMue_ is now known as TheMue === TheMue_ is now known as TheMue [12:35] SpamapS: i think rs is gonna be the way to go for sites similar to OMG, or ones setup to scale the same way [12:36] mainly because of their small servers that have 265mb ram but 4x2.2ghx proc and can sustain high cpu task [12:36] so bootstrap on a tiny [12:37] mysql on a something not considered here but seperate as is now [12:37] cluster or not etc [12:37] and each webhead ona tiny but lots of them [12:37] cuz right now the OMG webheads are maxing the cpu's but use very little other resources [12:38] so scaleing them out to many of these ultra tiny webheads that have lots of cpu makes sense [12:39] ( just thinking out loud here, as i prep the same charms to deploy websitedevops.com ) [12:40] oh and the tiny's are 0.01c hr , vs 0.08 for mediums on aws [12:41] so couple that with some rrdns and the lb setup we adopted [12:41] = win [13:04] SpamapS: http://cl.ly/GNEY <--- thats pretty avg accross the 3 current webheads , 15 to 25 Mb/s traffic, 30ish % of the 1.6 G ram used and 1.0 sys load [13:08] kinda strange to me, past experince has always been the ram not cpu on webheads [13:08] heh === almaisan-away is now known as al-maisan [14:30] bkerensa: Are you working on the OpenPhoto charm? [14:44] imbrandon: the reason the RAM isn't running out is because of the heavy caching, you don't need many active processes [14:45] marcoceppi: yes [14:46] bkerensa: ah, wasn't sure [14:46] * SpamapS wishes mediagoblin was easier to package, he'd finish it and get it promulgated [14:47] actually what I really wish is that pip installs used https [14:47] Time for a patch? [14:47] no, pypi doesn't have https [14:47] Though we *could* mirror pypi into a launchpad project..... [14:48] but, no, thats silly. Packaging isn't actually that hard, I just need to finish it [14:49] SpamapS: yea, just thought it was unique [14:49] bkerensa: I read your G+ post about openphoto and I was like "YES THEY HAVE A REPO" and then I saw the install script they made, which is like 90% charm ready [14:50] s/G+/planet/ [14:50] imbrandon: its actually really encouraging. :) [14:50] imbrandon: leaves RAM for VFS cache and stuff. The webheads are doing the cache of files, right? [14:53] marcoceppi: yep and I have it partially done and hope to have it fully done by the deadline... I might pick your brain to make it more frosty but right now I have to go pack :D [14:54] I should probably pack soon too. I have too many social engagements leading up to my departure Sunday morning [14:55] SpamapS: oh, btw, the new version of rubygems checks https certs... saw the release notes at conference [14:56] * m_3_ has to check that against the version we have in precise [14:59] SpamapS: yup [15:19] Can a relation hook both set and get relational data? [15:20] marcoceppi: yup [15:20] spectacular [15:21] m_3_: sweet [15:21] marcoceppi: the conversation keeps firing as long as either hook keeps _set_ting relation data [15:21] marcoceppi: there are a few, like mysql replication, that do several rounds of back and forth relation get/sets === al-maisan is now known as almaisan-away [15:27] I think that's what I want do to for gluster [15:28] instead of just having one giant shared fs, each charm should have it's own brick so the gluster client and gluster server need to keep up communication [15:28] marcoceppi: the coolest part of gluster is that we now have subordinates! [15:28] m_3_: I know! That's why I've started working on proper subordinate gluster-server/client charm pair [15:28] marcoceppi: that's the hard part... specifying the striping config you want from the clients [15:28] m_3_: I figured just config value for each gluster-client [15:29] there's only 4 different types of stripes [15:29] unfortunately this is only a segue charm pair so I can get back to work on my main charm of interest [15:31] marcoceppi: yeah, the client should get the makeup of the entire volume its currently using as config... not easy though [15:32] marcoceppi: maybe the stack startup script would specify the volume composition, then pass that into the config for the client... dunno how to discover that dynamically though. maybe see what clint did on ceph [15:36] * imbrandon gigles a little inside at seening his newest charm have "#!/usr/bin/env php" at the top of hooks [15:38] SpamapS: is it nessesary to have a requires in the metadata ? [15:42] imbrandon: we still have no solid time/day for cloudflare? [15:42] :( [15:42] bkerensa: no worries, it will work out [15:42] and if not there is always next time [15:43] imbrandon: Im sure they will be there pretty much 9 to 5 [15:43] :D [15:43] so long as a I ping @eastdakota half hour before we head out they can prepare [15:43] bkerensa: my goal is to be out on the left coast by this time next year anyhow :) [15:43] :) [15:43] for work/living? [15:43] yea [15:44] is that what were known as in the red states? [15:44] The left coast? [15:44] hahaha [15:44] pretty much [15:44] also matters what continent. [15:44] for good reason probably [15:44] :D [15:44] brb afk [15:44] Will `relation-list` in a peer relation list the current unit? [15:45] marcoceppi: i dont think so, thats why the 127 in the omg [15:45] lb relation [15:58] Gluster seems like it's this huge thing, but so far it looks really straight forward to setup [15:59] I see your incoming charm [16:00] Yeah I set it up, it was dead easy [16:04] anyone want to review locker charm? :) [16:07] marcoceppi: the question is, how to get charms to mount gluster [16:07] SpamapS: that's what I'm trying to figure out in an elegant fashion [16:08] Charms will have to expect gluster current [16:08] marcoceppi: or, perhaps, charms should just have a 'scope: container' relationship where they ask for a place to put their data [16:08] marcoceppi: interface: mount [16:09] marcoceppi: then gluster, nfs, and ceph, all have subordinates which speak that interface, and tell them "put it here..." and mount the data there [16:09] In fact, the way I have the gluster-client currently setup, it expects two relations, juju-info and a shared-fs relation where the charm tells gluster where the mount point should be [16:09] marcoceppi: \o/ [16:09] yeah, figured that was the best way for now [16:09] thats perfect [16:10] we should do NFS too... just for the "never do this" case. :) [16:10] SpamapS: already did that too :) [16:10] gluster-server charm has a direct NFS relation [16:10] marcoceppi: I'm going to give jcastro some cash so he can buy you beers all the nights I'm not there next week ;) [16:10] so you can use the gluster-client, or just add-relation to the nfs interface on the main charm [16:11] marcoceppi: the NFS interface isn't as fault-tolerant though.. is it? [16:11] and not as robust [16:11] so.. IMO.. leave it out [16:11] its for non Linux clients [16:12] SpamapS: http://i.imgur.com/hZf6H.jpg [16:18] ugh [16:18] getting a little confused [16:18] http://paste.ubuntu.com/967228/ [16:18] SpamapS marcoceppi ^^ [16:18] Have a Q.. when you have a one to many relation between say service A, B and C, e.g. A->C , A->B, when C breaks its relation with A, A's relation-broken hook doesn't appear to have a means of telling whether it's relation with B or C is being broken, so it seems impossible to make the hook idempotent, anyone know any answers? [16:19] SpamapS: get in line. [16:19] bbcmicrocomputer: there is a way, its just not obvious [16:19] bbcmicrocomputer: and many charms don't make use of it, because it only landed in recent juju versions [16:20] bbcmicrocomputer: $JUJU_RELATION_ID [16:20] bbcmicrocomputer: you can enumerate the relations with the relation-ids command [16:20] SpamapS: ah cool, will investigate [16:21] imbrandon: that looks good. assuming then that its just for serving static content? [16:21] yea i want the websites to determine the [16:21] dynaic part [16:21] but not sure how to handel that yet [16:22] e.g if they want to use uwsgi or php or whatever [16:22] imbrandon: in addition to 'webroot' perhaps have an interface 'fcgi-socket' ? [16:23] hrm [16:23] would that be an interface or just a config [16:24] imbrandon: youc an feed back 3 things .. fcgi-socket, static-wwebroot (for the "if it exists just serve from there"), and 'cache-url-patterns' for the thing to define where to look for cached pages. [16:25] as it is right now , i want this to be the base charm, not sub, and provide a nginx that is both a content on 8080 and 80 like the omg [16:25] imbrandon: interface definitely [16:25] and then yea have "sites" as subcharms [16:25] even frameworks and then sites [16:25] imbrandon: right, so nginx is primary, opens ports, etc. Then you have 'omg-wp' as a subordinate that drops its files in, and tells nginx how to serve it' [16:25] yea [16:25] exactyly [16:26] you can relate subs to other subs btw [16:26] yea , i was thinking this as the base and then sub be wp, then sub of that be omg-wp [16:26] was my plan [16:26] but also support like marcoceppi gluster etc [16:26] so while it will be a bit wonky, you can have 3 tiers of relations on a box.. like... nginx->php-fcgi->wordpress (and then get crazy, ->omg-themes) [16:26] thus the other optional bits [16:27] SpamapS: yea ,e xactly [16:27] well omg-something as it would be themes+plugins [16:27] but yea [16:27] imbrandon: perhaps I will write an Apache 2.4 charm w/ the same interfaces, and we can have a shootout. :) [16:27] :) rockin [16:27] lll [16:28] i rally want so seperate it too at some point [16:28] but not in time for the contest [16:28] imbrandon: one thing I want to do is enhance the http interface with an 'endpoint-host' that can be set by either side. I'm not sure which one should take precedence though.. upstream or downstream. [16:28] as in seperate the nginx lb+cache and the 80 [16:28] so apache could be the content serving [16:29] allo, mes amis.. So I'm looking at this page now: https://juju.ubuntu.com/docs/getting-started.html#configuring-your-environment. It says to run juju without arguements to generate an example enviroments.yaml.. That doesn't seem to work. [16:29] SpamapS: yea i had that question too, just wasent sure how to articualte it yet [16:29] Juju just responds with the argument list [16:29] balloons: did you look at ~/.juju/environments.yaml ? [16:30] SpamapS, right.. there's no folder created [16:30] that *should* work then yes [16:30] ? [16:30] balloons: interesting, I think we must have broken that [16:30] thats used to work [16:30] balloons: try 'juju bootstrap', does it create it then? [16:30] I think we made it so it only creates it if you try to do something now [16:30] since typing 'juju --help' was creating it [16:30] juju: error: too few arguments, and gives arg list [16:30] ahh [16:30] so docs probably need fixing [16:30] k, trying juju bootstrap [16:31] awesome: error: No environments configured. Please edit: /home/balloons/.juju/environments.yaml [16:31] so yea.. just needs updated I guess [16:32] balloons: if you're feeling adventurous.. 'bzr branch lp:juju/docs' .. and fix it. :) I'll merge it :) [16:32] balloons: otherwise file a bug here https://launchpad.net/juju/+filebug and we'll get to it right away [16:32] SpamapS: btw here in a few hours when i get frustrated enough with the nginx charm to switch gears i got some small updates to the newrelic one if you wouldent mind pushing, mostly stuff you sugested the other day [16:33] SpamapS, yea I had planned on branching and merging [16:33] I'll add it to the list of changes :-) [16:33] Also there's another way to setup a new environments.yaml.. 'jitsu setup-environment' ... a little more user friendly :) [16:33] * SpamapS adds ssl-hostname-verification to that [16:34] imbrandon: sweeeeet .. yeah just bug me. I'll be out on the road for a couple hours starting at 1200 my time tho. [16:34] kk [16:34] * imbrandon has to pack sometime today [16:36] btw i'm thinjking more downstrea, [16:36] as in the "lowest" sub should be able to overide anything its layerd on [16:36] imbrandon: I was thinking there will be times where it may be useful to define it at the upstream point, for instance if you want to host two apps under one proxy. [16:37] Is there an etiquette for assigning a charm request bug to yourself if someone else owns it? It looks like there has been no movement on it: [16:37] https://bugs.launchpad.net/charms/+bug/931835 [16:37] <_mup_> Bug #931835: Charm needed: Gitlab < https://launchpad.net/bugs/931835 > [16:37] which is quite likely for big multi-layerd apps [16:37] but.. those should really not be doing Host: inspection [16:37] yea [16:37] still sometimes you need to know what the Host is. :p [16:37] and would likely have [16:37] well [16:37] hrm [16:37] FunnyLookinHat: I'm actually working on that atm [16:37] marcoceppi, Ah - glad I asked. [16:38] yeah, I didn't claim it yet, becaues I was trying to get a hold of the author [16:38] Same here - but I was trying to do it through the ticket [16:38] mmm i forgot to file an nginx one, supose i should do that [16:38] So, IMO, Antono claimed it almost 2 months ago [16:38] marcoceppi, you can take it though :D [16:38] If you wanted to take a stab feel free, I'm trying to do a gluster, gitolite, gitlab combo to make a scalable github-esque setup [16:38] and has then gone dark [16:39] marcoceppi, oh geez... I just wanted a simple charm to deploy a gitlab setup so that people could easily either run git or sparkleshare types of stuff on their client [16:39] How does everybody feel about making the policy that you can only "claim" a new charm bug for 30 days before it goes back to available? [16:39] SpamapS, good idea. [16:39] Debian has recently done the same with ITP bugs for intent to package. [16:39] SpamapS: +1 [16:39] SpamapS: +1 [16:39] m_3_: ^^ [16:39] Ok, the motion carries. [16:39] w00t. [16:40] I will record that at https://juju.ubuntu.com/Charms [16:40] marcoceppi: are you definitely ready to work on it now, or do you want to give it to FunnyLookinHat ? [16:40] So if I need ruby 1.9.2 and only 1.9.1 is available in the repositories, should I make my charm download/build 1.9.2 or should I try to reference another charm somehow? I know one is in dev here: https://bugs.launchpad.net/charms/+bug/799879 [16:40] <_mup_> Bug #799879: Charm needed: rails (framework) < https://launchpad.net/bugs/799879 > [16:41] SpamapS: yeah, that sounds good [16:41] SpamapS: I plan to have it done for UDS, I'm kind of doing gluster, gitolite, then gitlab in that order, so FunnyLookinHat if you want to take the gitlab charm feel free [16:41] I'm going to try to throw it together for UDS - figured it'd be a decent entry for the competition [16:41] LOL [16:41] marcoceppi, You take it [16:41] I have others to do [16:41] magento is one that a lot of people seem to want [16:43] marcoceppi: please assign it to yourself [16:44] FunnyLookinHat: note that the package 1.9.1 is actually a newer version of ruby [16:44] m_3_, newer than 1.9.2 ? [16:44] 1.9.3p0 [16:44] How does that work? [16:44] Ooooh [16:44] it's just the package _name_ was chosen poorly imo [16:45] Should be ruby-current [16:45] FunnyLookinHat: also note that rvm is packaged now too [16:45] Or just ruby [16:45] Oh awesome [16:45] that makes it easier [16:47] much [16:48] FunnyLookinHat: the reason 1.9.1 was used was that it was wildly incompatible with 1.9.0 [16:48] FunnyLookinHat: so anything that depended on ruby1.9 wouldn't necessarily work with ruby1.9.1 [16:48] FunnyLookinHat: feel free to run with rails for the charm contest. the one in there is mine, but it's pretty naive and I really only use it for example hooks... it definitely needs some love across the board. should be split from apache/passenger so nginx, unicorn, thin, etc could be used. perhaps as a subordinate charm even [16:49] this unfortunately put the package maintainers in a bad position when 1.9.2 and 1.9.3 arrived, because they *are* compatible with 1.9.1 [16:49] yikes... really? [16:49] yep [16:49] its really ruby's fault [16:49] should have been 1.10, not 1.9.1 [16:49] no surprise, but still quite ugly [16:50] or 1.9.1.1 [16:50] heh [16:51] m_3_, this would be my FIRST charm... so I think I'll write the magento one first ( seems the easiest to deploy ) and then I might try my hand at something more complex. [16:51] I think ruby1.9.1 was the wrong choice [16:51] FunnyLookinHat: awesome! [16:51] But it was right before freeze for squeeze IIRC [16:55] Is there a concept of server vs. client when writing charms? IE only the server has specific configs, and the client another set. [16:55] Can you guys look at https://juju.ubuntu.com/Charms and make sure I specified that correctly? Specifically search for '30 days' and see the footnote [16:55] tobin: charms provide, and require things [16:55] tobin: typically servers provide, and clients require [16:56] Okay somewhat like dpkg. Got it. thank you SpamapS. [16:57] SpamapS: should there be an exception if there's a repository attached to the bug but no activity in 30 days? [16:58] alright -- juju bootstrap worked.. I see a small instance deployed [16:58] a few questions :-) can I control the instance size / type it creates when I bootstrap? [16:58] sorry I should say.. I bootstrapped to ec2 [16:59] balloons: yea with constraints [16:59] SpamapS: https://juju.ubuntu.com/Charms sounds good [17:00] imbrandon, thanks.. I see the docs on constraints.. looks simple [17:04] marcoceppi: hmmm... yeah, we sort of have to account for charms people write that attach to a bug but they might not wanna publish it into the store [17:04] not sure [17:05] so I issued the 'juju debug-log' command in one window, and a juju deploy mysql in another.. I don't seem to be getting any messages in the tailing log window though :-( Is there a log level I can set perhaps? [17:05] I guess the bugs are for the charms we're wanting in the store... so no, they'd still be fair game [17:05] cool [17:05] makes sense [17:06] nvm.. things are cranking in the log now :-) [17:06] marcoceppi: I don't think so, no. Though anybody else who takes it on would be a bit silly to not at least use that as a starting point. [17:06] balloons: "provider-delay" let's call it :) [17:06] that took a long time after I issued the commands and they returned successful.. interesting [17:06] SpamapS: makes sense [17:07] m_3_, yes makes sense.. [17:07] gotta spin up the machines, etc [17:07] marcoceppi: I'd like to favor the person interested *now*. :) [17:07] Not a bad idea [17:07] agree [17:08] The reason for the bug assignment bit is that we want to reduce duplication of effort. [17:08] ok, so "super last-minute drop everything" project isn't happening right now, so back to charm testing... [17:08] BTW, I saw no response to my maintainer: thread on juju.. so I'm going to start assigning maintainers soon. [17:08] BTW, we're rolling up test results to jenkins.qa.ubuntu.com [17:08] SpamapS: hey so, I'm thinking, kill the spreadsheet for charms [17:08] still working to get other provider tests to show too [17:08] and move to all bug reports. [17:08] jcastro: yes, please [17:09] m_3_: woot. Where is the main charmtester branch? I want to add explicit tests soon [17:09] jcastro: yes please [17:09] jcastro: spreadsheets are evil [17:09] m_3_: JINX! [17:09] oh wait [17:09] I said your name.. so.. yo're already free [17:09] lp:~mark-mims/charmers/charms/precise/charmtester/trunk [17:09] ha! [17:09] stupid IRC killing a children's game [17:09] lol [17:09] m_3_: you mean /charms/precise right, not /charmers/charms [17:10] surely we can remember others... /me digs around in there [17:10] crap... yeah [17:10] SpamapS: when can i use #!/usr/bin/php on install hook kthxbia! [17:10] lp:~mark-mims/charms/precise/charmtester/trunk [17:10] was reading other things while typing... [17:11] imbrandon: almost never :) [17:11] imbrandon: +1 for adding dep packages in metadata [17:11] :) [17:12] imbrandon: when the sun rises in the west and sets in the east [17:12] my install hook for nginx is seriously "apt-get update && apt-get install nginx php5-cli && php ./includes/install" [17:13] heh [17:14] imbrandon: nothing wrong with that [17:14] oh i know, just kinda pointless [17:15] and the rest all use #!/usr/bin/php :) [17:15] imbrandon: that's really pretty close to sourcing the php interpreter to consume the rest of the hook :) [17:16] ¯\(o_o)/¯ [17:16] we should put a snippet together to do that :) [17:16] :) [17:16] s/php/anything else/ of course :) [17:16] would work for ruby or anything [17:16] yea [17:17] yup [17:17] fairly obscene tho [17:17] lol yea [17:17] i see SpamapS cringing now [17:20] SpamapS: I just realized I haven't updated that branch in a while... git-bzr barfed on me a while ago and I haven't done the workaround... updating now [17:21] m_3_: speaking of yea the one you use is the one i do as well [17:21] git bzr ng [17:21] [17:21] git bzr clone lp:blah [17:21] etc [17:22] so sad that you guys can't just play nice w/ bzr. :) [17:22] heh it hates me [17:22] and i dont like the forks are called branches [17:22] :) [17:23] I don't like that git calls update revert, and revert merge, and merge .. wtf I am lost already :) [17:23] but I still use git when I am working on projects that use git [17:23] heh [17:24] thats it tho my projects are in git, not bzr, i just must use it to get reviewed :) [17:24] * imbrandon stops [17:25] * imbrandon hugs SpamapS :) [17:25] * m_3_ actually thinks there're more similarities than differences... [17:25] * SpamapS hugs err'body [17:25] yea there are quite a few, but i see bzr is more akin to hg, infact its damn near identical [17:25] just slower [17:26] There may come a day where we can have charms in git in the store [17:26] SpamapS, I think I did the docs merge properly (hope) https://code.launchpad.net/~nskaggs/juju/juju-bootstrap-fix/+merge/104781 [17:26] that day is not today [17:26] relation-list spits out service/unit correct? [17:26] marcoceppi: yeah [17:29] really my main main gripe is split between bzr merges seem dumb compared to gits ( as do pretty much any other vcs compared to git, there is a reason hg as a config option of [merge] git=true to use git for merging ) and the fact that bzr branches are actualy forks and not "in-place" like git branches with hardlinks, i REALLY like that feature [17:29] imbrandon: actually there's been recent work to have in place branches in bzr [17:30] as everybody seems to like that [17:30] dude, if that lands i'll convert [17:30] So question - I feel as though I'm creating a bad charm if all it does it download code, create a user, extract code and assign rights, and then setup a VirtualHost - am I missing something? [17:30] Heh, but what about rebase, and fastforward.. and the 3x speed difference? :) [17:30] i.e. is there some magic sauce where I'm supposed to make sure it can be duplicated or something ? [17:30] heh i can take one for the team [17:30] :) [17:30] imbrandon: talk to niemeyer, he wrote a plugin to do it [17:30] imbrandon: its called 'cobzr' you can probably find it [17:31] kk yea i'll check it out soonish [17:31] FunnyLookinHat: there's all sorts of stuff you can do to expand on charms... but the basics are pretty basic... on purpose [17:31] FunnyLookinHat: thats a great charm! [17:32] Ok awesome- just making sure I'm not submitting work that's worthless and has to be redone :D [17:32] FunnyLookinHat: if the charm stores user data locally.. you may want to find a way to store that in a shared place (like a database, or a shared filesystem), but that is where things get complicated and we all huddle together to scale-out a service. [17:32] SpamapS: great description [17:32] I really think if I spend a week on ways to scale-out w/ mysql I will be able to make mysql's 'add-unit' extremely useful. [17:33] SpamapS: yea i wanna get with you at uds too about a ndb mysql charm [17:33] Like, make it a replication ring, or maybe use galera to do sync-replication.. or screw it lets just make everything NDB cluster. [17:33] imbrandon: NDB's problem is network bandwidth [17:33] ahahaha [17:33] you need a ridiculous amount of it [17:33] right but its so sexy [17:34] imbrandon: sure, its sexy on infiniband. I doubt it performs on EC2 [17:34] FunnyLookinHat: we try to make suggestions for how to handle scaling, upgrades, external relations, etc in review too [17:34] m_3_, oh ok cool [17:34] SpamapS: i can see a whole env juju'd with ndb charms , then have your "web" farm in another juju env [17:34] just dunno how to make them talk yet [17:34] :) [17:36] external relations [17:36] mmmm [17:37] so i can upgrade or blow away my web farm but not my shared storage farm or my memcache farm or my sql farm [17:37] mmmm dreams [17:38] kinda like meta suboranates ? heh [17:39] imbrandon: take a peek at the mongodb charm's config.yaml file... note that the replicaset_master can be specified by host/port explicitly. It's pretty manual, but it's a way of bridging between two juju envs [17:40] nice, i was sure i wasnt the first to think of it [17:41] imbrandon: so the charm needs to be written to handle both "kinds" of relations [17:41] right [17:41] small price [17:41] imbrandon: but it's what we have atm [17:41] yea, better than full on manual [17:41] imbrandon: also subordinates can easily be used to proxy between two envs [17:42] in all sorts of interesting ways [17:42] SpamapS: ahh hadent thought of that [17:42] especially now that we have out-of-hook relation-set capability [17:42] ha! [17:42] yes [17:42] hrmm, intresting times we now live in [17:42] just need dynamic relation capability and we can have a juju-proxy charm [17:43] * imbrandon just needs to get a job where he can write charms all day [17:43] m_3_: watch your back! [17:43] SpamapS: if you move a merge proposal to "merged" will launchpad merge it? [17:43] ;) [17:43] ha! [17:43] bkerensa: not sure, that would be cool though [17:43] lol [17:43] imbrandon: yeah, you end up doing all sorts of other stuff too :) [17:43] :) [17:43] SpamapS: ok well for some reason I have review privileges on a branch [17:43] >.< [17:44] and I reviewed some code and it looks fine [17:44] :P [17:44] bkerensa: lp:juju/docs is owned by ~charm-contributors [17:44] Basically anybody who asks real nice can update the documentation. :) [17:44] bkerensa: yeah, we've got a bit of disconnect between charms and our charm process and launchpad atm [17:45]