[00:00]  * SpamapS EOD's
[02:38] <adam_g> 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] <jimbaker> 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] <jimbaker> along the lines of other recent fixes we have had
[04:51] <adam_g> jimbaker: cool. if theres an SRU bug somewhere, i can verify. or let me know, and ill file one
[12:35] <imbrandon> 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] <imbrandon> mainly because of their small servers that have 265mb ram but 4x2.2ghx proc and can sustain high cpu task
[12:36] <imbrandon> so bootstrap on a tiny
[12:37] <imbrandon> mysql on a something not considered here but seperate as is now
[12:37] <imbrandon> cluster or not etc
[12:37] <imbrandon> and each webhead ona  tiny but lots of them
[12:37] <imbrandon> cuz right now the OMG webheads are maxing the cpu's but use very little other resources
[12:38] <imbrandon> so scaleing them out to many of these ultra tiny webheads that have lots of cpu makes sense
[12:39] <imbrandon> ( just thinking out loud here, as i prep the same charms to deploy websitedevops.com )
[12:40] <imbrandon> oh and the tiny's are 0.01c hr , vs 0.08 for mediums on aws
[12:41] <imbrandon> so couple that with some rrdns and the lb setup we adopted
[12:41] <imbrandon> = win
[13:04] <imbrandon> 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] <imbrandon> kinda strange to me, past experince has always been the ram not cpu on webheads
[13:08] <imbrandon> heh
[14:30] <marcoceppi> bkerensa: Are you working on the OpenPhoto charm?
[14:44] <SpamapS> imbrandon: the reason the RAM isn't running out is because of the heavy caching, you don't need many active processes
[14:45] <bkerensa> marcoceppi: yes
[14:46] <marcoceppi> bkerensa: ah, wasn't sure
[14:46]  * SpamapS wishes mediagoblin was easier to package, he'd finish it and get it promulgated
[14:47] <SpamapS> actually what I really wish is that pip installs used https
[14:47] <marcoceppi> Time for a patch?
[14:47] <SpamapS> no, pypi doesn't have https
[14:47] <SpamapS> Though we *could* mirror pypi into a launchpad project.....
[14:48] <SpamapS> but, no, thats silly. Packaging isn't actually that hard, I just need to finish it
[14:49] <imbrandon> SpamapS: yea, just thought it was unique
[14:49] <marcoceppi> 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] <marcoceppi> s/G+/planet/
[14:50] <SpamapS> imbrandon: its actually really encouraging. :)
[14:50] <SpamapS> imbrandon: leaves RAM for VFS cache and stuff. The webheads are doing the cache of files, right?
[14:53] <bkerensa> 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] <marcoceppi> I should probably pack soon too. I have too many social engagements leading up to my departure Sunday morning
[14:55] <m_3_> 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] <imbrandon> SpamapS: yup
[15:19] <marcoceppi> Can a relation hook both set and get relational data?
[15:20] <m_3_> marcoceppi: yup
[15:20] <marcoceppi> spectacular
[15:21] <SpamapS> m_3_: sweet
[15:21] <m_3_> marcoceppi: the conversation keeps firing as long as either hook keeps _set_ting relation data
[15:21] <SpamapS> marcoceppi: there are a few, like mysql replication, that do several rounds of back and forth relation get/sets
[15:27] <marcoceppi> I think that's what I want do to for gluster
[15:28] <marcoceppi> 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] <m_3_> marcoceppi: the coolest part of gluster is that we now have subordinates!
[15:28] <marcoceppi> m_3_: I know! That's why I've started working on proper subordinate gluster-server/client charm pair
[15:28] <m_3_> marcoceppi: that's the hard part... specifying the striping config you want from the clients
[15:28] <marcoceppi> m_3_: I figured just config value for each gluster-client
[15:29] <marcoceppi> there's only 4 different types of stripes
[15:29] <marcoceppi> unfortunately this is only a segue charm pair so I can get back to work on my main charm of interest
[15:31] <m_3_> marcoceppi: yeah, the client should get the makeup of the entire volume its currently using as config... not easy though
[15:32] <m_3_> 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] <imbrandon> SpamapS: is it nessesary to have a requires in the metadata ?
[15:42] <bkerensa> imbrandon: we still have no solid time/day for cloudflare?
[15:42] <bkerensa> :(
[15:42] <imbrandon> bkerensa: no worries, it will work out
[15:42] <imbrandon> and if not there is always next time
[15:43] <bkerensa> imbrandon: Im sure they will be there pretty much 9 to 5
[15:43] <bkerensa> :D
[15:43] <bkerensa> so long as a I ping @eastdakota half hour before we head out they can prepare
[15:43] <imbrandon> bkerensa: my goal is to be out on the left coast by this time next year anyhow :)
[15:43] <imbrandon> :)
[15:43] <bkerensa> for work/living?
[15:43] <imbrandon> yea
[15:44] <bkerensa> is that what were known as in the red states?
[15:44] <bkerensa> The left coast?
[15:44] <imbrandon> hahaha
[15:44] <imbrandon> pretty much
[15:44] <tooth> also matters what continent.
[15:44] <bkerensa> for good reason probably
[15:44] <bkerensa> :D
[15:44] <imbrandon> brb afk
[15:44] <marcoceppi> Will `relation-list` in a peer relation list the current unit?
[15:45] <imbrandon> marcoceppi: i dont think so, thats why the 127 in the omg
[15:45] <imbrandon> lb relation
[15:58] <marcoceppi> Gluster seems like it's this huge thing, but so far it looks really straight forward to setup
[15:59] <jcastro> I see your incoming charm
[16:00] <jcastro> Yeah I set it up, it was dead easy
[16:04] <bkerensa> anyone want to review locker charm? :)
[16:07] <SpamapS> marcoceppi: the question is, how to get charms to mount gluster
[16:07] <marcoceppi> SpamapS: that's what I'm trying to figure out in an elegant fashion
[16:08] <marcoceppi> Charms will have to expect gluster current
[16:08] <SpamapS> marcoceppi: or, perhaps, charms should just have a 'scope: container' relationship where they ask for a place to put their data
[16:08] <SpamapS> marcoceppi: interface: mount
[16:09] <SpamapS> 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] <marcoceppi> 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] <SpamapS> marcoceppi: \o/
[16:09] <marcoceppi> yeah, figured that was the best way for now
[16:09] <SpamapS> thats perfect
[16:10] <SpamapS> we should do NFS too... just for the "never do this" case. :)
[16:10] <marcoceppi> SpamapS: already did that too :)
[16:10] <marcoceppi> gluster-server charm has a direct NFS relation
[16:10] <SpamapS> 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] <marcoceppi> so you can use the gluster-client, or just add-relation to the nfs interface on the main charm
[16:11] <SpamapS> marcoceppi: the NFS interface isn't as fault-tolerant though.. is it?
[16:11] <marcoceppi> and not as robust
[16:11] <SpamapS> so.. IMO.. leave it out
[16:11] <SpamapS> its for non Linux clients
[16:12] <marcoceppi> SpamapS: http://i.imgur.com/hZf6H.jpg
[16:18] <imbrandon> ugh
[16:18] <imbrandon> getting a little confused
[16:18] <imbrandon> http://paste.ubuntu.com/967228/
[16:18] <imbrandon> SpamapS marcoceppi ^^
[16:18] <bbcmicrocomputer> 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] <jcastro> SpamapS: get in line.
[16:19] <SpamapS> bbcmicrocomputer: there is a way, its just not obvious
[16:19] <SpamapS> bbcmicrocomputer: and many charms don't make use of it, because it only landed in recent juju versions
[16:20] <SpamapS> bbcmicrocomputer: $JUJU_RELATION_ID
[16:20] <SpamapS> bbcmicrocomputer: you can enumerate the relations with the relation-ids command
[16:20] <bbcmicrocomputer> SpamapS: ah cool, will investigate
[16:21] <SpamapS> imbrandon: that looks good. assuming then that its just for serving static content?
[16:21] <imbrandon> yea i want the websites to determine the
[16:21] <imbrandon> dynaic part
[16:21] <imbrandon> but not sure how to handel that yet
[16:22] <imbrandon> e.g if they want to use uwsgi or php or whatever
[16:22] <SpamapS> imbrandon: in addition to 'webroot' perhaps have an interface 'fcgi-socket' ?
[16:23] <imbrandon> hrm
[16:23] <imbrandon> would that be an interface or just a config
[16:24] <SpamapS> 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] <imbrandon> 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] <SpamapS> imbrandon: interface definitely
[16:25] <imbrandon> and then yea have "sites" as subcharms
[16:25] <imbrandon> even frameworks and then sites
[16:25] <SpamapS> 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] <imbrandon> yea
[16:25] <imbrandon> exactyly
[16:26] <SpamapS> you can relate subs to other subs btw
[16:26] <imbrandon> yea , i was thinking this as the base and then sub be wp, then sub of that be omg-wp
[16:26] <imbrandon> was my plan
[16:26] <imbrandon> but also support like marcoceppi gluster etc
[16:26] <SpamapS> 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] <imbrandon> thus the other optional bits
[16:27] <imbrandon> SpamapS: yea ,e xactly
[16:27] <imbrandon> well omg-something as it would be themes+plugins
[16:27] <imbrandon> but yea
[16:27] <SpamapS> imbrandon: perhaps I will write an Apache 2.4 charm w/ the same interfaces, and we can have a shootout. :)
[16:27] <imbrandon> :) rockin
[16:27] <imbrandon> lll
[16:28] <imbrandon> i rally want so seperate it too at some point
[16:28] <imbrandon> but not in time for the contest
[16:28] <SpamapS> 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] <imbrandon> as in seperate the nginx lb+cache and the 80
[16:28] <imbrandon> so apache could be the content serving
[16:29] <balloons> 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] <imbrandon> SpamapS: yea i had that question too, just wasent sure how to articualte it yet
[16:29] <balloons> Juju just responds with the argument list
[16:29] <SpamapS> balloons: did you look at ~/.juju/environments.yaml ?
[16:30] <balloons> SpamapS, right.. there's no folder created
[16:30] <balloons> that *should* work then yes
[16:30] <balloons> ?
[16:30] <SpamapS> balloons: interesting, I think we must have broken that
[16:30] <imbrandon> thats used to work
[16:30] <SpamapS> balloons: try 'juju bootstrap', does it create it then?
[16:30] <SpamapS> I think we made it so it only creates it if you try to do something now
[16:30] <SpamapS> since typing 'juju --help' was creating it
[16:30] <balloons> juju: error: too few arguments, and gives arg list
[16:30] <imbrandon> ahh
[16:30] <SpamapS> so docs probably need fixing
[16:30] <balloons> k, trying juju bootstrap
[16:31] <balloons> awesome: error: No environments configured. Please edit: /home/balloons/.juju/environments.yaml
[16:31] <balloons> so yea.. just needs updated I guess
[16:32] <SpamapS> balloons: if you're feeling adventurous.. 'bzr branch lp:juju/docs' .. and fix it. :) I'll merge it :)
[16:32] <SpamapS> balloons: otherwise file a bug here https://launchpad.net/juju/+filebug and we'll get to it right away
[16:32] <imbrandon> 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] <balloons> SpamapS, yea I had planned on branching and merging
[16:33] <balloons> I'll add it to the list of changes :-)
[16:33] <SpamapS> 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] <SpamapS> 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] <imbrandon> kk
[16:34]  * imbrandon has to pack sometime today
[16:36] <imbrandon> btw i'm thinjking more downstrea,
[16:36] <imbrandon> as in the "lowest" sub should be able to overide anything its layerd on
[16:36] <SpamapS> 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] <FunnyLookinHat> 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] <FunnyLookinHat> https://bugs.launchpad.net/charms/+bug/931835
[16:37] <_mup_> Bug #931835: Charm needed: Gitlab <Juju Charms Collection:New for antono> < https://launchpad.net/bugs/931835 >
[16:37] <SpamapS> which is quite likely for big multi-layerd apps
[16:37] <SpamapS> but.. those should really not be doing Host: inspection
[16:37] <imbrandon> yea
[16:37] <SpamapS> still sometimes you need to know what the Host is. :p
[16:37] <imbrandon> and would likely have
[16:37] <imbrandon> well
[16:37] <imbrandon> hrm
[16:37] <marcoceppi> FunnyLookinHat: I'm actually working on that atm
[16:37] <FunnyLookinHat> marcoceppi, Ah - glad I asked.
[16:38] <marcoceppi> yeah, I didn't claim it yet, becaues I was trying to get a hold of the author
[16:38] <FunnyLookinHat> Same here - but I was trying to do it through the ticket
[16:38] <imbrandon> mmm i forgot to file an nginx one, supose i should do that
[16:38] <SpamapS> So, IMO, Antono claimed it almost 2 months ago
[16:38] <FunnyLookinHat> marcoceppi, you can take it though  :D
[16:38] <marcoceppi> 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] <SpamapS> and has then gone dark
[16:39] <FunnyLookinHat> 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] <SpamapS> 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] <FunnyLookinHat> SpamapS, good idea.
[16:39] <SpamapS> Debian has recently done the same with ITP bugs for intent to package.
[16:39] <marcoceppi> SpamapS: +1
[16:39] <imbrandon> SpamapS: +1
[16:39] <SpamapS> m_3_: ^^
[16:39] <SpamapS> Ok, the motion carries.
[16:39] <FunnyLookinHat> w00t.
[16:40] <SpamapS> I will record that at https://juju.ubuntu.com/Charms
[16:40] <SpamapS> marcoceppi: are you definitely ready to work on it now, or do you want to give it to FunnyLookinHat ?
[16:40] <FunnyLookinHat> 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) <developers> <Juju Charms Collection:In Progress by mark-mims> < https://launchpad.net/bugs/799879 >
[16:41] <m_3_> SpamapS: yeah, that sounds good
[16:41] <marcoceppi> 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] <FunnyLookinHat> I'm going to try to throw it together for UDS - figured it'd be a decent entry for the competition
[16:41] <FunnyLookinHat> LOL
[16:41] <FunnyLookinHat> marcoceppi, You take it
[16:41] <FunnyLookinHat> I have others to do
[16:41] <FunnyLookinHat> magento is one that a lot of people seem to want
[16:43] <SpamapS> marcoceppi: please assign it to yourself
[16:44] <m_3_> FunnyLookinHat: note that the package 1.9.1 is actually a newer version of ruby
[16:44] <FunnyLookinHat> m_3_, newer than 1.9.2 ?
[16:44] <m_3_> 1.9.3p0
[16:44] <FunnyLookinHat> How does that work?
[16:44] <FunnyLookinHat> Ooooh
[16:44] <m_3_> it's just the package _name_ was chosen poorly imo
[16:45] <FunnyLookinHat> Should be ruby-current
[16:45] <m_3_> FunnyLookinHat: also note that rvm is packaged now too
[16:45] <FunnyLookinHat> Or just ruby
[16:45] <FunnyLookinHat> Oh awesome
[16:45] <m_3_> that makes it easier
[16:47] <FunnyLookinHat> much
[16:48] <SpamapS> FunnyLookinHat: the reason 1.9.1 was used was that it was wildly incompatible with 1.9.0
[16:48] <SpamapS> FunnyLookinHat: so anything that depended on ruby1.9 wouldn't necessarily work with ruby1.9.1
[16:48] <m_3_> 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] <SpamapS> 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] <m_3_> yikes... really?
[16:49] <SpamapS> yep
[16:49] <SpamapS> its really ruby's fault
[16:49] <SpamapS> should have been 1.10, not 1.9.1
[16:49] <m_3_> no surprise, but still quite ugly
[16:50] <imbrandon> or 1.9.1.1
[16:50] <imbrandon> heh
[16:51] <FunnyLookinHat> 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] <SpamapS> I think ruby1.9.1 was the wrong choice
[16:51] <m_3_> FunnyLookinHat: awesome!
[16:51] <SpamapS> But it was right before freeze for squeeze IIRC
[16:55] <tobin> 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] <SpamapS> 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] <SpamapS> tobin: charms provide, and require things
[16:55] <SpamapS> tobin: typically servers provide, and clients require
[16:56] <tobin> Okay somewhat like dpkg. Got it. thank you SpamapS.
[16:57] <marcoceppi> SpamapS: should there be an exception if there's a repository attached to the bug but no activity in 30 days?
[16:58] <balloons> alright -- juju bootstrap worked.. I see a small instance deployed
[16:58] <balloons> a few questions :-) can I control the instance size / type it creates when I bootstrap?
[16:58] <balloons> sorry I should say.. I bootstrapped to ec2
[16:59] <imbrandon> balloons: yea with constraints
[16:59] <m_3_> SpamapS: https://juju.ubuntu.com/Charms sounds good
[17:00] <balloons> imbrandon, thanks.. I see the docs on constraints.. looks simple
[17:04] <m_3_> 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] <m_3_> not sure
[17:05] <balloons> 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] <m_3_> I guess the bugs are for the charms we're wanting in the store... so no, they'd still be fair game
[17:05] <marcoceppi> cool
[17:05] <marcoceppi> makes sense
[17:06] <balloons> nvm.. things are cranking in the log now :-)
[17:06] <SpamapS> 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] <m_3_> balloons: "provider-delay" let's call it :)
[17:06] <balloons> that took a long time after I issued the commands and they returned successful.. interesting
[17:06] <marcoceppi> SpamapS: makes sense
[17:07] <balloons> m_3_, yes makes sense..
[17:07] <balloons> gotta spin up the machines, etc
[17:07] <SpamapS> marcoceppi: I'd like to favor the person interested *now*. :)
[17:07] <marcoceppi> Not a bad idea
[17:07] <m_3_> agree
[17:08] <SpamapS> The reason for the bug assignment bit is that we want to reduce duplication of effort.
[17:08] <m_3_> ok, so "super last-minute drop everything" project isn't happening right now, so back to charm testing...
[17:08] <SpamapS> BTW, I saw no response to my maintainer: thread on juju.. so I'm going to start assigning maintainers soon.
[17:08] <m_3_> BTW, we're rolling up test results to jenkins.qa.ubuntu.com
[17:08] <jcastro> SpamapS: hey so, I'm thinking, kill the spreadsheet for charms
[17:08] <m_3_> still working to get other provider tests to show too
[17:08] <jcastro> and move to all bug reports.
[17:08] <m_3_> jcastro: yes, please
[17:09] <SpamapS> m_3_: woot. Where is the main charmtester branch? I want to add explicit tests soon
[17:09] <SpamapS> jcastro: yes please
[17:09] <imbrandon> jcastro: spreadsheets are evil
[17:09] <SpamapS> m_3_: JINX!
[17:09] <SpamapS> oh wait
[17:09] <SpamapS> I said your name.. so.. yo're already free
[17:09] <m_3_> lp:~mark-mims/charmers/charms/precise/charmtester/trunk
[17:09] <m_3_> ha!
[17:09] <SpamapS> stupid IRC killing a children's game
[17:09] <imbrandon> lol
[17:09] <SpamapS> m_3_: you mean /charms/precise right, not /charmers/charms
[17:10] <m_3_> surely we can remember others... /me digs around in there
[17:10] <m_3_> crap... yeah
[17:10] <imbrandon> SpamapS: when can i use #!/usr/bin/php on install hook kthxbia!
[17:10] <m_3_> lp:~mark-mims/charms/precise/charmtester/trunk
[17:10] <m_3_> was reading other things while typing...
[17:11] <marcoceppi> imbrandon: almost never :)
[17:11] <m_3_> imbrandon: +1 for adding dep packages in metadata
[17:11] <imbrandon> :)
[17:12] <SpamapS> imbrandon: when the sun rises in the west and sets in the east
[17:12] <imbrandon> my install hook for nginx is seriously "apt-get update && apt-get install nginx php5-cli && php ./includes/install"
[17:13] <imbrandon> heh
[17:14] <marcoceppi> imbrandon: nothing wrong with that
[17:14] <imbrandon> oh i know, just kinda pointless
[17:15] <imbrandon> and the rest all use #!/usr/bin/php :)
[17:15] <m_3_> imbrandon: that's really pretty close to sourcing the php interpreter to consume the rest of the hook :)
[17:16] <marcoceppi> ¯\(o_o)/¯
[17:16] <m_3_> we should put a snippet together to do that :)
[17:16] <imbrandon> :)
[17:16] <m_3_> s/php/anything else/ of course :)
[17:16] <imbrandon> would work for ruby or anything
[17:16] <imbrandon> yea
[17:17] <m_3_> yup
[17:17] <m_3_> fairly obscene tho
[17:17] <imbrandon> lol yea
[17:17] <imbrandon> i see SpamapS cringing now
[17:20] <m_3_> 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] <imbrandon> m_3_: speaking of yea the one you use is the one i do as well
[17:21] <imbrandon> git bzr ng

[17:21] <imbrandon> git bzr clone lp:blah
[17:21] <imbrandon> etc
[17:22] <SpamapS> so sad that you guys can't just play nice w/ bzr. :)
[17:22] <imbrandon> heh it hates me
[17:22] <imbrandon> and i dont like the forks are called branches
[17:22] <imbrandon> :)
[17:23] <SpamapS> I don't like that git calls update revert, and revert merge, and merge .. wtf I am lost already :)
[17:23] <SpamapS> but I still use git when I am working on projects that use git
[17:23] <imbrandon> heh
[17:24] <imbrandon> 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] <imbrandon> yea there are quite a few, but i see bzr is more akin to hg, infact its damn near identical
[17:25] <imbrandon> just slower
[17:26] <SpamapS> There may come a day where we can have charms in git in the store
[17:26] <balloons> SpamapS, I think I did the docs merge properly (hope) https://code.launchpad.net/~nskaggs/juju/juju-bootstrap-fix/+merge/104781
[17:26] <SpamapS> that day is not today
[17:26] <marcoceppi> relation-list spits out service/unit correct?
[17:26] <SpamapS> marcoceppi: yeah
[17:29] <imbrandon> 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] <SpamapS> imbrandon: actually there's been recent work to have in place branches in bzr
[17:30] <SpamapS> as everybody seems to like that
[17:30] <imbrandon> dude, if that lands i'll convert
[17:30] <FunnyLookinHat> 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] <SpamapS> Heh, but what about rebase, and fastforward.. and the 3x speed difference? :)
[17:30] <FunnyLookinHat> i.e. is there some magic sauce where I'm supposed to make sure it can be duplicated or something ?
[17:30] <imbrandon> heh i can take one for the team
[17:30] <imbrandon> :)
[17:30] <SpamapS> imbrandon: talk to niemeyer, he wrote a plugin to do it
[17:30] <SpamapS> imbrandon: its called 'cobzr' you can probably find it
[17:31] <imbrandon> kk yea i'll check it out soonish
[17:31] <m_3_> FunnyLookinHat: there's all sorts of stuff you can do to expand on charms... but the basics are pretty basic... on purpose
[17:31] <SpamapS> FunnyLookinHat: thats a great charm!
[17:32] <FunnyLookinHat> Ok awesome- just making sure I'm not submitting work that's worthless and has to be redone  :D
[17:32] <SpamapS> 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] <m_3_> SpamapS: great description
[17:32] <SpamapS> 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] <imbrandon> SpamapS: yea i wanna get with you at uds too about a ndb mysql charm
[17:33] <SpamapS> 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] <SpamapS> imbrandon: NDB's problem is network bandwidth
[17:33] <imbrandon> ahahaha
[17:33] <SpamapS> you need a ridiculous amount of it
[17:33] <imbrandon> right but its so sexy
[17:34] <SpamapS> imbrandon: sure, its sexy on infiniband. I doubt it performs on EC2
[17:34] <m_3_> FunnyLookinHat: we try to make suggestions for how to handle scaling, upgrades, external relations, etc in review too
[17:34] <FunnyLookinHat> m_3_, oh ok cool
[17:34] <imbrandon> SpamapS: i can see a whole env juju'd with ndb charms , then have your "web" farm in another juju env
[17:34] <imbrandon> just dunno how to make them talk yet
[17:34] <imbrandon> :)
[17:36] <imbrandon> external relations
[17:36] <imbrandon> mmmm
[17:37] <imbrandon> 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] <imbrandon> mmmm dreams
[17:38] <imbrandon> kinda like meta suboranates ? heh
[17:39] <m_3_> 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] <imbrandon> nice, i was sure i wasnt the first to think of it
[17:41] <m_3_> imbrandon: so the charm needs to be written to handle both "kinds" of relations
[17:41] <imbrandon> right
[17:41] <imbrandon> small price
[17:41] <m_3_> imbrandon: but it's what we have atm
[17:41] <imbrandon> yea, better than full on manual
[17:41] <SpamapS> imbrandon: also subordinates can easily be used to proxy between two envs
[17:42] <m_3_> in all sorts of interesting ways
[17:42] <imbrandon> SpamapS: ahh hadent thought of that
[17:42] <SpamapS> especially now that we have out-of-hook relation-set capability
[17:42] <m_3_> ha!
[17:42] <m_3_> yes
[17:42] <imbrandon> hrmm, intresting times we now live in
[17:42] <SpamapS> 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] <SpamapS> m_3_: watch your back!
[17:43] <bkerensa> SpamapS: if you move a merge proposal to "merged" will launchpad merge it?
[17:43] <SpamapS> ;)
[17:43] <m_3_> ha!
[17:43] <SpamapS> bkerensa: not sure, that would be cool though
[17:43] <bkerensa> lol
[17:43] <m_3_> imbrandon: yeah, you end up doing all sorts of other stuff too :)
[17:43] <imbrandon> :)
[17:43] <bkerensa> SpamapS: ok well for some reason I have review privileges on a branch
[17:43] <bkerensa> >.<
[17:44] <bkerensa> and I reviewed some code and it looks fine
[17:44] <bkerensa> :P
[17:44] <SpamapS> bkerensa: lp:juju/docs is owned by ~charm-contributors
[17:44] <SpamapS> Basically anybody who asks real nice can update the documentation. :)
[17:44] <m_3_> bkerensa: yeah, we've got a bit of disconnect between charms and our charm process and launchpad atm
[17:45] <bkerensa> LOL
[17:45] <bkerensa> m_3_: your not a bot?
[17:45] <bkerensa> :D
[17:45] <SpamapS> bkerensa: no, change it back to Approved, launchpad did not merge it ;)
[17:45] <SpamapS> as cool as that would be
[17:45] <bkerensa> SpamapS: yeah I saw it
[17:45] <m_3_> SpamapS: found my notes from series upgrade btw... there's still a couple of danglers
[17:45] <bkerensa> its moved back
[17:45] <m_3_> bkerensa: ha!.. nope, not a bot
[17:46] <m_3_> bkerensa: all my names start with 'm'... and you _don't_ wanna turn on irc highlighting for 'mmm' :)
[17:47] <imbrandon> lol
[17:47] <m_3_> SpamapS: but now we have unpromulgate... thanks!
[17:48] <SpamapS> oh that reminds me
[17:48] <SpamapS> I pushed adams crazy juju testing lab as the official rabbitmq-server branch
[17:48] <m_3_> SpamapS: btw, if you wanna see _exactly_ what the lp script did on series upgrade, lp:charms/nova-compute is still in a pristinely screwed up state (i.e., we haven't tried to fix it yet)
[17:49] <SpamapS> adam_g: is there any reason not to include your special testing lab fork in the main charm store? I'd rather there only be one place that is generally consumed.
[17:49] <m_3_> basically, compare lp:charms/nova-compute ( -> lp:~charmers/charms/precise/nova-compute/precise ) with lp:~charmers/charms/precise/nova-compute/trunk
[17:50] <SpamapS> bkerensa: you can go ahead and push that fix into the branch btw
[17:50] <bkerensa> SpamapS: How do I push it in?
[17:50] <bkerensa> =/
[17:50]  * bkerensa has never merged 
[17:50] <bkerensa> do tell
[17:50] <balloons> :-) more doc changes..  juju is yelling at me for having a revision info in my metadata.yaml file.. looks like there is a revision file now.. the docs should be updated
[17:50] <m_3_> when lp:charms/nova-compute was updated from ...oneiric.. there was another branch on lp:~charmers/charms/precise/nova-compute/trunk, so the lp script renamed it to lp:~charmers/charms/precise/nova-compute/precise and aliased accordingly
[17:50] <SpamapS> bkerensa: there's a first time for everything! :)
[17:50] <bkerensa> SpamapS: do tell how
[17:50] <SpamapS> bkerensa: simplest way, 'bzr branch <<the branch you want to merge in>>'
[17:50] <balloons> I'll do my best to edit that also
[17:51] <bkerensa> then bzr merge?
[17:51] <SpamapS> bkerensa: then if there is only one commit, just 'bzr push lp:juju/docs'
[17:51] <bkerensa> ahh
[17:51] <bkerensa> k
[17:51] <m_3_> SpamapS: so the net is the aliased branch is old... needs to be unpromulgated and then the lp:~charmers/charms/precise/nova-compute/trunk branch needs to be promulgated in its place
[17:51] <SpamapS> bkerensa: if there are like, 10 crazy commits, you just want one in the mainline changelog, so you 'bzr branch lp:juju/docs', cd into that dor, and 'bzr merge ../whatever' and then commit as one thing.. 'Merging doc fix...'
[17:53] <m_3_> SpamapS: that's what happened with rabbitmq-server, but there was lots of manual "intervention" to try to fix this without an unpromulgate :(
[17:53] <SpamapS> Yeah
[17:53] <SpamapS> I think you named a brnch FML or something
[17:53] <m_3_> well... yes
[17:54] <m_3_> I should write this down for next release upgrade so we know exactly what we're gonna try to prevent
[17:54] <SpamapS> m_3_: I assume this is the one we want: lp:~charmers/charms/precise/nova-compute/trunk
[17:54] <m_3_> SpamapS: I think that's correct... looking at the history
[17:54] <balloons> can someone confirm the revision file is automatically created now, or is this something I should create and update?
[17:55] <SpamapS> m_3_: I'm pretty sure all we need to do is rename the trunk -> series name *and* get the charm store to ignore the branch name for official branches
[17:55] <m_3_> SpamapS: hmmm
[17:55] <SpamapS> balloons: you'll have to create it and update it whenever you want users to see the new charm.
[17:56] <balloons> SpamapS, hmm.. I don't remember making one.. but there is a file now called revision with a '1' in it
[17:56] <balloons> in my charm
[17:57] <SpamapS> m_3_: Ok so the fix is this: bzr branch lp:charms/nova-compute ; cd nova-compute ; charm unpromulgate ; cd .. ; mv nova-compute nova-compute-busted ; bzr branch lp:~charmers/charms/precise/nova-compute/trunk nova-compute ; cd nova-compute ; bzr push :parent ; charm promulgate
[17:57] <jcastro> woo, lots of charm activity lately!
[17:58] <imbrandon> offer shiney toys and that happens :)
[17:59] <SpamapS> jcastro: at least 60 commits per day since Feb 12.
[17:59] <m_3_> SpamapS: right, that sounds perfect... did you already do it, or shall I?
[17:59] <SpamapS> m_3_: I want you to do it, so I can confirm there's nothing special on my machine :)
[17:59] <m_3_> SpamapS: will do
[18:01] <SpamapS> m_3_: I'm also interested in seeing what happens when I 'bzr pull' from the aliased branch
[18:01] <jcastro> hazmat: speaking of, we might want to fix the charts ^^^^
[18:01] <SpamapS> m_3_: so let me know when you're done
[18:01] <m_3_> SpamapS: also my notes say it barfed on zookeeper, statusnet, nova-compute, nova-cloud-controller, rabbitmq-server
[18:01] <m_3_> I'll do nova-compute now... one sec
[18:02] <bkerensa> SpamapS: ok balloons stuff is up
[18:02] <SpamapS> bkerensa: woot!
[18:02] <bkerensa> I thought there was much more to all that
[18:02] <bkerensa> =/
[18:03] <SpamapS> I think the website refreshes every 15 min or maybe 60 min, not sure
[18:04] <m_3_> SpamapS: http://paste.ubuntu.com/967444/ I use this machine for bzr/lp all the time, so it has my lp id / keys
[18:07] <SpamapS> m_3_: are you ssh'd to it? that breaks
[18:08] <SpamapS> I don't know why
[18:08] <m_3_> probably... lemme see if I can turn that off
[18:08] <SpamapS> but launchpadlib won't work if you ssh into a machine that also has your lpcreds in gnome keyring
[18:08] <m_3_> oh... I see
[18:08] <m_3_> yeah, other desk one sec
[18:08] <SpamapS> yeah, its dumb
[18:09] <SpamapS> I'm sure there's a way to get it to ignore the gnome keyring creds, but I don't know what it is
[18:09] <imbrandon> works fine if osx keyring has them heh
[18:09] <imbrandon> i;m sure it dont look in the osx keyring on osx tho
[18:12] <SpamapS> imbrandon: does lplib work on os x?
[18:14] <imbrandon> yup
[18:14] <imbrandon> use it all the time
[18:14] <imbrandon> its how bzr knows who i am when pushing and such
[18:15] <imbrandon> like i said pretty sure it ignores the osx keyring tho
[18:23] <balloons> hmm.. ok, how do I undeploy a charm if you will?
[18:23] <SpamapS> balloons: juju destroy-service foo
[18:24] <SpamapS> balloons: note that the machines are not terminated
[18:24] <balloons> right, is destory enviroment the only way to kill a machine?
[18:24] <balloons> or can i selectively kill off a machine?
[18:25] <balloons> as far as I can tell, I don't see destroy-service mentioned in the docs anywhere
[18:25] <m_3_> SpamapS: ok, so I keep gettings can't determine launchpad location from bzr branch
[18:25] <marcoceppi> -relation-departed the $JUJU_REMOTE_UNIT is the unit which "departed", correct?
[18:26] <SpamapS> m_3_: you might have forgotten the 'bzr push' step?
[18:26] <SpamapS> marcoceppi: correct
[18:27] <SpamapS> balloons: terminate-machine to terminate a specific machine
[18:27] <m_3_> nope, this was during unpromulgate... editing the .bzr/branch/branch.conf manually worked though
[18:27] <SpamapS> m_3_: OOOHHH right, I forgot a step .. ;)
[18:27] <SpamapS> m_3_: bzr push :parent
[18:28] <m_3_> SpamapS: yeah, did that
[18:28] <m_3_> but the branch it put there didn't let me unpromulgate
[18:28] <SpamapS> m_3_: promulgate just looks at the push branch , so if bzr info shows something else, thats what is wrong
[18:28] <m_3_> had to manually change it to the one I wanted
[18:28] <SpamapS> m_3_: you can tack on '--remember' to change it
[18:28] <SpamapS> oh
[18:28] <SpamapS> you know that makes sense
[18:28] <SpamapS> m_3_: right you have to push to the explicit name
[18:28] <SpamapS> didn't think about that
[18:28] <m_3_> I can get the url if you want... it was +branch/..../
[18:29] <m_3_> either way... that's working... lemme promulgate the other branch
[18:29] <SpamapS> m_3_: we should also look at the charm store and see if it is listing our new ones in a while
[18:29] <SpamapS> m_3_: we might have to bump the revision file
[18:29] <SpamapS> though actually it probably doesn't seem them cause their name is 'precise'
[18:29] <SpamapS> so the new one named 'trunk' will show up
[18:30]  * SpamapS facepalms
[18:30] <SpamapS> ETOOMANYVARIABLES
[18:31] <balloons> when you deploy a charm, does it pull from bzr or your local files? I made changes but they aren't reflecting in my deploy.. seems like perhaps bzr plays a part here
[18:32] <balloons> in short, if I make a change to my charm, what do I have to do before doing another test deploy from my local repo?
[18:32] <adam_g> SpamapS: those testing charms are full of little hacks that are specific to our deployment and environment
[18:32] <m_3_> SpamapS: ok, that worked... lp:charms/nova-compute points to the right place... yeah, we might have to invalidate the store cache entry
[18:32] <adam_g> SpamapS: things like wget'ing stuff from a local webserver, granting ubuntu user permission to stuff it shouldn't have, etc
[18:33] <adam_g> SpamapS: im curious, why is hte rabbit charm causing problems but hte other stacked ones are not?
[18:33] <m_3_> adam_g: they are :)
[18:33] <SpamapS> aye
[18:33] <SpamapS> adam_g: all the ones that we had versions of in precise before the branch-distro script got run caused issues
[18:33] <m_3_> adam_g: I'll send you an email with a detailed description of what happened...
[18:33] <SpamapS> balloons: depends on how you deployed it
[18:34] <balloons> SpamapS, haha..
[18:34] <SpamapS> balloons: if you used local: .. then the local dir is scanned for a revision file, and if it is different from the one you already have in your environment, the new charm is deployed, otherwise the one already in the env is deployed
[18:34] <balloons> ah-ha!
[18:34] <m_3_> adam_g: just the lp tool we used does some special things for pre-existing target branches
[18:34] <balloons> that pesky revision file!
[18:35] <SpamapS> balloons: there is a switch for deploy -u, which will force the revision file to be bumped up by 1
[18:35] <m_3_> adam_g: nothing about your charms/branches at all
[18:35] <balloons> so everytime I make a change I have to bump that file?
[18:35] <SpamapS> balloons: also you can use the 'upgrade-charm' command to bump the rev and upload the new version for an existing deployment
[18:35] <balloons> hmm.. I think I'll like this deploy -u
[18:35] <balloons> I'm just trying to test and debug the charm I have
[18:36] <balloons> so iteratively deploying, changing, deploying
[18:37] <balloons> I'll try the deploy -u and see if that solves my issue.. it's interesting nonetheless
[18:37] <SpamapS> balloons: one thing I do is to make the 'upgrade-charm' hook do 'stop;install;config-changed;start' so that I can just iterate with 'ugprade-charm'
[18:37] <SpamapS> actually I think that order is wrong though.. I need to change it to stop;install;start;config-changed
[18:38] <SpamapS> (or perhaps juju should just do that for me.. since it makes the most sense. ;)
[18:38] <balloons> SpamapS, hmm.. I'd be happy to take up your best practice on this
[18:38] <balloons> let me know :-)
[18:40] <m_3_> SpamapS: ok, so that looks good... I'll go ahead and catch the rest of the upgrade errors
[18:41] <SpamapS> m_3_: ok, I think we can avoid this at branch-distro time by renaming any 'trunk' branches in quantal to 'quantal', then running the branch-distro.. then do the mass rename from quantal->trunk
[18:42] <SpamapS> we're also going to have to look at the problem that branch-distro *locks* all existing branches
[18:42] <m_3_> SpamapS: ah... yeah... so just rearrange the order... good idea
[18:42] <SpamapS> since the charm store won't let us push anything except 'trunk'.. that means we can't have like, a -updates branch that we then change the pointer to
[18:42] <m_3_> SpamapS: I'm writing up the whole process so we don't forget... send it to the list
[18:42] <SpamapS> I think we have to fix the charm store
[18:43] <SpamapS> it should blindly publish anything that has an official pointer
[18:43] <m_3_> dunno... it should ignore feature branches though and only display trunk huh?
[18:44] <imbrandon> or master
[18:44]  * SpamapS gets the hose
[18:44] <imbrandon> hahahahaha
[18:44] <m_3_> ha!
[18:44]  * imbrandon about choked on my mt dew
[18:44] <m_3_> imbrandon: actually the difference between "trunk" and "master" names has saved me many times in git-bzr-ng screwups
[18:45] <m_3_> but yes... not your point
[18:45] <imbrandon> hahah same here on hg <--> git
[18:45] <imbrandon> at penton
[18:49] <SpamapS> imbrandon: http://bit.ly/IOdIgm
[18:49] <m_3_> great pic
[18:50] <m_3_> clarise
[18:50] <m_3_> or rather clarisssssssse
[18:50] <imbrandon> hahha
[18:51] <SpamapS> m_3_: the trunk name should totally be the name it uses for publish/notpublish per-user branches. But there's no reason to apply that same rule to official branches
[18:51] <SpamapS> The other option though, is to unlock those branches for updates
[18:51] <SpamapS> which I'd actually be in support of for Ubuntu as well.
[18:51] <SpamapS> Because having different branches for different pockets is confusing and does not work well.
[19:01]  * imbrandon like the lp:~imbrandon/charms/nginx/trunk for devel , /charms/nginx/precise for precise and /charms/nginx/oneiric for oneiric
[19:01] <imbrandon> personaly, thats how i do other non charm projects
[19:01]  * m_3_ still trying to figure out what a pocket is on lp
[19:01] <imbrandon> trunk or master or whatever is the main devel branch, then named branches for stage or prod etc
[19:02] <imbrandon> in this case releases
[19:03] <SpamapS> imbrandon: lp:~imbrandon/charms/precise/nginx/trunk ...
[19:03] <SpamapS> m_3_: pocket is release, security, updates, proposed
[19:03] <imbrandon> i realize that but thats reversed
[19:03] <SpamapS> m_3_: release is the pocket assumed in the absence of a pocket ;)
[19:04] <SpamapS> imbrandon: the reason we want them to be this way, is that its not just your charm. You are well integrated with all the other charms.
[19:04] <balloons> hmm.. juju debug-log seems to have some crazy lag on it when using it in connection with wget
[19:04] <imbrandon> sure thats what the /charms/ name space does
[19:04] <SpamapS> Making them their own little islands will fail at the de-duplication of effort that we're striving for.
[19:05] <SpamapS> imbrandon: but we want each release to work well as a whole
[19:05] <imbrandon> no no your mising a part there
[19:05] <imbrandon> sure
[19:05] <balloons> any idea why that might be? 2012-05-04 11:59:35,646 unit:vivo/4: hook.output ERROR: ..... .......... ....
[19:05] <balloons> 2012-05-04 11:59:35,647 unit:vivo/4: hook.output ERROR: ...... .......... 38% 22.7M 7s
[19:05] <SpamapS> as the OS moves on, we want the charms to move, as a whole, with the OS.
[19:05] <imbrandon> the release loosk for the $release banch
[19:05] <SpamapS> what I don't want is a bunch of "if release == oldnbusted: else ...
[19:05] <imbrandon> um no
[19:05] <balloons> the file downloaded minutes ago, but the debug log is still slowly scrolling through lines that look like that, giving download status updates
[19:05] <imbrandon> not at all
[19:05] <imbrandon> where do you get that ?>
[19:06] <SpamapS> imbrandon: thats what will happen if we leave the release out of the url. And if we put it at the end, its purely psychological.. they won't be seen as a whole "precise" set of charms or "quantal" set of charms.
[19:06] <imbrandon> e.g my drupal modules ( as well as thousands of others ) are that way, and in no way have "if release -- blah"
[19:06] <SpamapS> its entirely psychological
[19:06] <imbrandon> no no
[19:07] <imbrandon> wow no
[19:07] <imbrandon> what it comes down to is shared code
[19:07] <imbrandon> notthing more
[19:07] <imbrandon> your way causes fragmentation
[19:07] <SpamapS> precise/nginx means precise's nginx. nginx/precise means the nginx that works on precise..
[19:07] <imbrandon> the other allows hsared
[19:07] <imbrandon> right
[19:08] <imbrandon> exactly, and thats what it is
[19:08] <SpamapS> and lp:charms/nginx means "where you do dev now"
[19:08] <imbrandon> no thats where sotre releases are
[19:08] <imbrandon> no one devs there
[19:08] <SpamapS> its actually not, the store releases lp:charms/precise/nginx
[19:08] <SpamapS> and lp:charms/oneiric/nginx
[19:09] <imbrandon> still no chared code , forces forking, is bad
[19:09] <imbrandon> shared*
[19:09] <SpamapS> imbrandon: we have a session scheduled for this actually
[19:09] <imbrandon> thus the way drupal has done it now for years just for this very reason
[19:09] <SpamapS> I'm not sure what code you want to share tho?
[19:09] <imbrandon> i seriously say we take a book from them
[19:09] <imbrandon> all of it
[19:09] <SpamapS> drupal is a single project though
[19:09] <imbrandon> not much is gonna chage
[19:09] <imbrandon> SpamapS: no its not
[19:09] <SpamapS> I don't know if a distribution of things loosely coupled works like a project
[19:09] <imbrandon> its 10000's of smaller ones
[19:10] <SpamapS> ah ok
[19:10] <imbrandon> no i mean drupal as in every module included on drupal.org
[19:10] <imbrandon> like 6k+
[19:10] <imbrandon> they all follow one rule
[19:11] <imbrandon> dev is done in ~/projectname/master ( its git blah , trunk here ) and then
[19:11] <imbrandon> ~/prijectname/7.x branch for
[19:11] <imbrandon> drupal 7
[19:11] <imbrandon> and 6.x branch for 6
[19:11] <imbrandon> etc
[19:11] <imbrandon> that way its not forked
[19:12] <imbrandon> its the same git repo
[19:12] <SpamapS> imbrandon: btw, I forwarded your newrelic-php charm to the newrelic sales guy who contacted me. He forwarded it along to their dev/products teams.
[19:12] <imbrandon> just a branch, so when 8.x comes out, git branch 8.x from the current dev and get to work
[19:12] <SpamapS> imbrandon: ah I think thats semantics. We're really just branching the same mainline.. lp:charms/charmname, and then we can easily merge backward to all previous releases.
[19:12] <imbrandon> and merge back into each other as its applicable
[19:13] <imbrandon> SpamapS: SWEET
[19:13] <imbrandon> i have the others ready just about too
[19:13] <imbrandon> as in python , ruby and sysmon
[19:13] <imbrandon> more than that is gonna wait post uds
[19:14] <SpamapS> imbrandon: in fact our session that we have scheduled is about discussing whether we should automate that process by saying if the tests pass, it gets auto-pushed back to non-diverged branches
[19:14] <imbrandon> sysmon being the "main" newrelic namespace
[19:14] <imbrandon> SpamapS: yea and see its much easier to track that way
[19:14] <imbrandon> if its in the same branch named space
[19:14] <SpamapS> imbrandon: totally. I'd rather have releases improve constantly and only make it manual when we actually break stuff.
[19:14] <imbrandon> SpamapS: drupals automated testbot does it
[19:14] <imbrandon> right
[19:14] <SpamapS> sounds like we're already headed in the same direction then
[19:15] <SpamapS> ok crap time got away from me
[19:15] <SpamapS> time to hit the road
[19:15] <SpamapS> bbl
[19:15] <imbrandon> l8tr
[19:15] <flepied> what are the pre-requesites to run ec2 instances ?
[19:15] <hazmat> jcastro, re charts? commit activity?
[19:15] <imbrandon> flepied: just a amazon acount iirc ( with attached cc info )
[19:16] <m_3_> SpamapS: whats the name of the tool that lp originally ran?
[19:16] <m_3_> bump-series?
[19:16] <flepied> imbrandon, I saw you need an S3 bucket at least
[19:17] <SpamapS> m_3_: branch-distro
[19:17]  * SpamapS is gone
[19:19] <jcastro> hazmat: yeah, commit activity, remember you said it was wrong?
[19:19] <hazmat> jcastro, yeah.. it only captures 10 commits per charm
[19:19] <hazmat> i'll take a look at fixing it up this weekend, at conference at the moment (mongo)
[19:21] <flepied> I have the following error: ERROR SSH forwarding error: bind: Cannot assign requested address
[19:26] <flepied> after bootstrapping an ec2 environment
[19:26] <flepied> all commands report this error...
[19:27] <tobin> Can someone help me understand what 'interface: monitor' means within a metadata.yaml file. I believe I understand how requires and provides somewhat works, but unsure what monitor means.
[19:27] <nathwill> query: is $JUJU_RELATION_ID specific to a service unit, or is that generic to the relationship between the services?
[19:28] <tobin> For instance, the ganglia charm has a relation name of "ganglia-node" with a interface set to monitor. Why is this needed?
[19:33] <bkerensa> imbrandon: thoughts on Cloudfront costs?
[19:40] <victorp> I am trying to boostrap an ec2 environment, juju boostrap command finishes ok but juju status gives me an invalid SSH error
[19:40] <victorp> help?
[19:43] <victorp> jcastro, ^^
[19:43] <flepied> victorp, same error here
[19:43] <victorp> flepied, did you manage to fix it?
[19:47] <flepied> no
[20:04] <victorp> oh well
[20:04] <victorp> I cant get it to work
[20:05] <victorp> maybe daviey can help
[20:14] <flepied> got it to work
[20:14] <flepied> oops already gone
[20:27] <imbrandon> bkerensa: more expensive than compeditors but same as s3, so if your just serviing alteady out of s3 kinda nuts not to
[20:27] <bkerensa> imbrandon: ahh I was one it for a few because maxcdn got blocked by my host
[20:27] <bkerensa> :D
[20:27] <bkerensa> but now its sorted... their VP had people call my host and get their ranges white listed
[20:27] <bkerensa> and then told me how much he is enjoyinh 12.04
[20:27] <bkerensa> :D
[20:27] <imbrandon> maxcdn = shoddy and a pita to use IMHO
[20:28] <bkerensa> imbrandon: NetDNA/MaxCDN has sponsored me for three years
[20:28] <bkerensa> ;)
[20:28] <bkerensa> and I get unlimited terabytes at no cost ;p
[20:28] <imbrandon> cool, still a PITA to use
[20:28] <imbrandon> ;)
[20:28]  * imbrandon dont like origin pull 
[20:29] <bkerensa> you like push zones?
[20:29] <bkerensa> =/
[20:29] <imbrandon> and automation, yes, then i'm in control
[20:30] <imbrandon> or tranparent like cloudfront or cloudflare
[20:30] <bkerensa> :P
[20:31] <bkerensa> I think at the end of the year Im going to ask NetDNA to end my MaxCDN sponsorship and transition me to CloudCache
[20:31] <bkerensa> :D
[20:31] <imbrandon> really i'm more of a fan of abstraction tho, provider transparent
[20:31] <imbrandon> thus when juju grows cdn wings i'll be happy
[20:31] <marcoceppi> Making upstreams put their downloads behind SSL: https://twitter.com/#!/marcoceppi/status/198139725402488833 https://twitter.com/#!/johnmark/status/198509648603656194
[20:32] <imbrandon> marcoceppi: nice
[21:52] <victorp> flepied, hey - got it working
[21:53] <_mup_> Bug #994855 was filed: Error messages are logged twice in the command line <juju:New> < https://launchpad.net/bugs/994855 >
[22:08] <_mup_> Bug #994863 was filed: juju needs ssh keys in launchpad but we don't tell the user that. <juju:New> < https://launchpad.net/bugs/994863 >