[02:51] zomg , jcastro you round ? [02:53] * imbrandon just figured out a nginx loadbal config that allows the site to do 600+ concurrent req/s AND stay under 50ms ( yes 50 not 500 ) response time [02:53] * imbrandon does a lil dance [02:54] ( oh, off a m1.small still ) === flepied_ is now known as flepied [06:29] so quiet in here all weekend [06:29] imbrandon: clearly you have been drinking :) [06:29] nah [06:29] lol [06:29] why is that tho ? [06:30] figured maybe you were a quiet drunk [06:32] :) [06:33] any help needed with charms ? [06:33] SpamapS: check this hottness out [06:33] http://paste.ubuntu.com/942087/ [06:34] put that bad boy in the /etc/nginx/loadbalancer config and boom , sweetness enchews [06:34] even works with admin logins :) [06:35] well chang the IP's to something other than my internal ones but yes [06:36] next trick is gonna see what the limit on the cache size is, so i can throw /mnt/nginx on a ramdisk [06:36] safely [06:38] and no, i am a quiet coder, loud thinker, been coding alot this weekend ( php ) , more than normal [06:42] SpamapS: think we could try to psudo implment that new way of storage at UDS ? i'm keen on getting it done but i havent grasp the juju codebase yet, mostly due to me still not clear on a few of the basics and trying to run before i walk but I'm sure 10 min of facetime with marcoceppi, you, or someone else will clear that right up at uds ( just how i initially learn things i guess ) [06:42] oh and Go rocks, not as much like php as i first thought, but still rocks [06:44] * imbrandon goes back to his php code for the moment :) [06:47] SpamapS: oh and my non scientific test do show that for some strange reason unix:/some/php.sock is indeed slower ( well not slower but fails faster with 503's ) than 127.0.0.1:9000 , no idea WHY yet, like if its open file descriptors or what is the issue because that just _seems_ wrong in my gut, but yea [06:47] why would you do a ramdisk? can't nginx just cache in RAM? [06:47] ummm not certain, probably not without a sep module like the memcache module [06:48] it does most everything filebased by default and most things are modules [06:48] memcache as in, memcached, or it has another cache module for RAM cache? [06:48] that said there likely is noe [06:48] one* [06:48] memcached [06:48] only used as a example cuz its a sep module in nginx [06:49] that would be silly [06:49] what would ? [06:49] that it can only do file based in core ? [06:50] nginx tries to be very very slim in code and make all extras modules, even some of the stuff we use like proxy is technicaly a module and not in core proper [06:50] its like php and all its blah.so extensions [06:50] imbrandon: well if its one big file like varnish does, that would make sense... you can just use VFS then [06:50] but they are done at compile time only iirc [06:50] nah its tons of small files [06:50] * SpamapS notes that his laptop has but 10 minutes of battery left [06:51] imbrandon: thats a huge fail [06:51] IMO [06:51] closing a file == syncing a file [06:51] like /mnt/nginx/[1-9]/[a=f] [06:51] a-f [06:51] yeah, so thats nice for simpler coding, but you dn't get to take much advantage of vfs [06:52] well yea i'm sure there are better ways , but thats just how i set it up to begin with , see how its specified on line .... [06:52] proxy_cache_path /mnt/nginx levels=1:2 keys_zone=microcache:5m max_size=1000m; [06:52] so i'm sure there is optinos to that line where we could make it even more uber [06:53] but even like that it did 625 concurrent users and 0 errors or time outs from blitz.io [06:53] and stayed under 100ms , mostly 50ms [06:53] response time from clai , and the server was in vegas [06:53] s/was/is [06:53] cali* [06:54] imbrandon: nice. [06:54] but yea , that was just the "refrence" line from the wiki, i'm sure we can tweak it lots more [06:54] and research a little etc [06:54] ok, battery is about to go dead even with powertop showing 8.0W of power usage [06:55] heh ok, gnight [06:55] imbrandon: should just thieve varnish's mmap method [06:55] still in san fran ? [06:55] kk [06:55] nooo [06:55] lol [06:55] I was only there from the morning to evening [06:55] ahh [06:56] kids.. wife.. all get in the way of fun stuff like conferences ;) [06:56] cool cool, i got some stuff to do early in the morning, but i've already woken for the day so just ping me later and i'll show yta the whole config set [06:56] that i'm working on [06:56] hahaha yea [06:57] btu yea that was a great start i thought, and its a dropin for our current LB config on omg [06:57] but* [06:58] need to start thinking in more generic terms [06:58] so really anything like apache or rails could sit on the other side of that upstream in this config too [06:58] I want to get omg's specific stuff into a subordinate [06:58] anyway [06:58] yea i have been, i've been making sure all the stuff is sep [06:58] battery.. dead.. later [06:58] infact even the web and lp i want sep [06:58] later [06:58] lb* [06:59] hrm , yea infact i'm going to make this into a sub charm right now [06:59] its in a perfect state to do so [07:00] as a nginx loadbal microcache proxy [07:00] * imbrandon looks for that charm init command === amithkk is now known as Andrew__ === Andrew__ is now known as AndrewStrong === AndrewStrong is now known as ubuntu__ === ubuntu__ is now known as xubuntu === xubuntu is now known as a === a is now known as b_ === b_ is now known as amithkk [11:09] imbrandon: I hope that's in the omg-wp repo [11:09] i'm actually commiting it now [11:09] or trying to . [11:09] had some conflicts [11:09] but yea [11:09] it is or will be in less than 5 min [11:09] marcoceppi: good weekend ? [11:09] imbrandon: excellent [11:10] yes, lots of little wordpress tweaks, but if this does what it needs to we'll be golden [11:10] marcoceppi: yea i got lots of impovements i've tested over the weekend while it was quite, bad part is i'm not QUITE ready like inches away though, but i got somewhere to be this morning till like lunch [11:11] That's fine, we can wait to deploy later this afternoon [11:11] nice, and i was lookign too its best if we do use totalcache to use apc backend not file, then nginx dont have to be touched as far as total cache, its just a normal setup + our other tweaks at that point [11:12] * imbrandon heads to the other room [13:05] m_3: jamespage when we make the juu blueprints, it needs to be "servercloud-juju-blah-blah" [13:06] m_3: I have 3 charm growth blueprints I will file too. === jcastro_ is now known as jcastro [14:07] jcastro, servercloud-q-juju-blah-blah please :-) [14:14] jamespage: you don't need the q, but whatever [14:15] jcastro: hmm - has that changed? [14:16] lp tracks the UDS series, it's just people always put in the letter anyway [14:16] you don't need it, but if you want to do it that way that's fine too [14:16] robbiew specifically asked us todo it that way for the servercloud track [14:17] oh ok then, do what he tells you [14:18] jcastro, BTW can you change the message for this channel - might be a little out-of-date 'Charm content ends monday!...' === jcastro changed the topic of #juju to: Charms at http://jujucharms.com || Want to write a charm? http://juju.ubuntu.com/Charms [14:32] jcastro, ta! [14:33] jamespage: you were correct on the animal letter btw, mail sent to -devel again [14:34] jcastro, glad to be of nit-picking service! [15:32] robbiew: hey, can we put juju backports in the shiny new cloud repository? [15:32] that would be cool I think [15:35] jcastro: No, I'd prefer folks use the PPAs and/or Backports for juju [15:35] ok [15:35] I would have pushed openstack the same way [15:35] but there will be times when folks want to freeze on a certain version [15:36] I guess the same could be said about juju [15:37] jcastro: tbh, there's really no difference between the cloud archive and a ppa [15:37] just naming [15:38] but people get worried when you ask them to add a ppa :P [15:38] ok, I was just wondering if delivering juju with that at the same time would be a good idea like milestone wise, etc. [15:38] "you not only get the backend, you get the front piece too!" [15:39] juju needs a cadenced release first ;) [15:39] well I was hoping that would make us do that, heh [16:27] robbiew: won't the cloud archive also use the regualar ubuntu signing key? [16:28] jcastro: juju is going to have something similar, but it should not be coupled to openstack. [16:29] SpamapS: I guess...it's just a PPA mirrored off archive.ubuntu.com ;) [16:31] robbiew: so they'll still have to add an apt key [16:31] which, IMO, would freak people out *more* than a PPA [16:32] SpamapS: your opinion in the minority ;) [16:33] it's not about the tech...it's about the "name" [16:33] Personal Package Archive scares people [16:33] I admit it might not be logical...but neither are people :P [16:34] https://bugs.launchpad.net/charms/+bug/966484 [16:34] <_mup_> Bug #966484: New Charm: Kusaba X < https://launchpad.net/bugs/966484 > [16:34] https://bugs.launchpad.net/charms/+bug/964936 [16:34] <_mup_> Bug #964936: Drupal Charm: superchared Drupal charm with nginx,, apc, php-fpm, all setup to scale to the moon and be Best Practices. < https://launchpad.net/bugs/964936 > [16:34] 2 in the queue [16:34] SpamapS: we can get these in by thursday right? For some sort of cycle-ending WOO? [16:41] robbiew: I suppose the one win is that you'll get it as part of the mirroring of the archive and won't have to poke a hole in a firewall to get to ppa's [16:42] exxxxxactly ;) [16:46] jcastro: need to be available to do 0-day SRU reviews but I'll try to squeeze these in === carif_ is now known as carif [18:57] <_mup_> juju/retry-client-for-cli r532 committed by kapil.thangavelu@canonical.com [18:57] <_mup_> use retry client for cli [18:57] negronjl_: hey, how would you feel about moving your REST api into juju-jitsu? [19:24] negronjl: great works by the way (jrapi) === hspencer is now known as hspencer[afk] [19:55] is there any plan to support dynamic creation of vm in juju based on load or other metrics ? [19:58] flepied: you can do that now. stick the client on a thing that knows what the load is, and when load goes up, 'juju add-unit X' [19:59] SpamapS, any example of this ? [20:00] flepied: none I've seen, but its such a simple concept.. you can do it with icinga/nagios [20:03] SpamapS, seems easy, I'll try [20:03] another question is there any plan to use chef/puppet with juju ? [20:04] flepied: I created puppet charms last week... [20:04] flepied: and some people have toyed with using puppet to assert the system state they want from install/etc. [20:04] flepied: juju really doesn't want to define that.. it executes stuff ... you choose what it executes :) [20:06] SpamapS, yes I got that. Just wanted to see if this was going to be the way to write charm in the future or not... [20:12] flepied: If we define a single way, we will be losing all the existing goodness that people have for their services. [20:13] flepied: the main advantage of juju is that we can connect these unrelated stacks to form a new, bigger stack [20:15] SpamapS, ok makes sense but you also need to ease the integration of charms together so having standard ways to do thing could help [20:16] flepied: right, we've been doing a lot of shell scripts so they're easy to read for that reason. [20:18] SpamapS, is there any way I can help ? I have some spare time... [20:25] flepied: are you an expert on any service that might be useful in the cloud? [20:25] flepied: if so, write a charm... using puppet or chef would be a bonus so people can see how that works [20:26] flepied: one method I think that will work is to use the facter custom facts plugin to have a charm's hooks store relation/config settings data, and then just keep running the puppet ruleset using those facts. [20:28] SpamapS, ok I'll look at that [20:29] flepied: Also the charms we have now are all kind of untested.. we need people to put them through the paces and apply real world scaling/configurability to them [20:31] flepied: oh, and if nobody said this to you yet.. WELCOME! :) [20:31] SpamapS, thx :) [20:33] SpamapS, I'll try to see how to test charms. I saw there is a ftest service running [20:37] flepied: yeah that just bootstraps and runs a few of the basic charms [20:37] do you have a jenkins server testing the charms ? === lamont` is now known as lamont [20:46] SpamapS, from this table http://jujucharms.com/interfaces, it seems monitoring (nagios) and ngnix (gunicorn) cannot work as they require something that is not provided anywhere... [20:47] flepied: actually we just landed a feature which will enable that [20:47] flepied: its called 'subordinate charms' and we need to work on the documentation a bit :) [20:48] flepied: re charms in jenkins, 'http://charmtests.markmims.com' .. but there is one running precise charms now too [20:48] m_3: ^^ I can has precise, preeeaassseeee [20:48] SpamapS, yes I experimented it the other day and it's working fine [20:50] flepied: also nagios I think can be modified to be able to relate to anything since there is now a 'juju-info' relation for every service [20:52] SpamapS, yes that's the trick to avoid having explicit relations [20:53] flepied: though I think there should be a general 'monitoring' interface which can feed back basic instructions on what to monitor... [20:53] flepied: like, mysql can tell nagios to monitor it, and if the nagios charm has mysql specific monitors, it will use them [20:54] SpamapS, yes that'd cool [20:55] flepied: make it generic enough and we can sub in newer, more scalable monitoring stuff :) [20:55] * SpamapS pushes support for subordinates into charm-tools [20:56] m_3: why didn't I think of this. the charmtester should run 'charm proof' against all charms as well [22:03] bac: hrm, I feel like we left something undone with charm helpers and your buildbot stuff [22:04] SpamapS: gmb and i have a couple of proposed branches and there was the packaging issue. [22:05] SpamapS: it is on our radar but we haven't bugged you about it assuming you were swamped ATM [22:06] bac: I seem to recall that we wanted to get python-shelltoolbox packaged on its own [22:07] SpamapS: yes, and portable to lucid [22:08] as needed by our buildbot slaves inside the containers [22:09] when using juju, are people using chef/puppet to do the base system configuration? I understand writing charms to do an application, but when configuring the system (ldap, accounts, mounts, etc), it seems like chef/puppet make more sense then a bunch of charms. I'd think that there should be a charm to deploy/configure/run chef/puppet, right? [22:10] xmltok: There's a new way to deploy puppet/chef/??? along side your charms to do things like system policy. [22:10] xmltok: http://jujucharms.com/search?search_text=puppet [22:10] xmltok: I'm clint-fewbar btw ;) [22:11] aha! perfect [22:11] http://jujucharms.com/~clint-fewbar/precise/puppet [22:11] xmltok: its still just a proof of concept though. [22:11] exactly what i was thinking [22:12] oh hey cool, mod_spdy charm. nice [22:12] xmltok: yeah that needs some work too.. it just assumes 127.0.0.1:80 will have a service to forward to :) === hspencer[afk] is now known as hspencer[mtg]