[00:44] http://www.calm.com/ [01:01] cmaloney: kinda neat [01:01] the guided sessions is a good idea [01:03] Yeah, thought that was pretty cool [01:03] I should put that as a recurring event during work [01:03] post-deploys: calm.com [01:03] ;) [01:03] maybe pre-deploy, too [01:04] alright, pizza time [01:04] laters! [01:12] Laterness. [01:20] greg-g: lol [15:08] good morning [15:22] morning [15:23] Good morning [15:24] hmm, so someone ripped up bookie and built a 'base app' not sure what to think about that [15:24] https://github.com/mazzaroth/initpyr/blob/master/models/__init__.py left some crud at the base of this file lol [15:25] I think someone is trying to learn [15:25] yea, cool [15:25] but yeah, that's quite the hack-job. [15:30] https://bmark.us/bmark/readable/b14779371a9beb [15:34] performance reviews? [15:37] Microsoft's Performance Reviews [15:37] Their reputation preceeds them [15:37] heh [15:37] http://www.reddit.com/r/chrome/comments/1q9sw6/google_will_no_longer_allow_windows_users_to/ [15:38] Not sure if you saw this. [15:38] I don't think it affects bookie anymore [15:38] yea, saw that. No, we're in the store [15:38] doing the beta installs would be effected [15:38] Yeah [15:38] but there's always ways around things. [15:38] manual installs work fine, and there's the new add-on manager app for chrome [15:39] I can't help but think this is a "good thing" [15:39] https://chrome.google.com/webstore/detail/chrome-apps-developer-too/ohmmkhmmmpcnpikjeljgnaoabkaalbgc?hl=en [15:40] And a work-around that smacks of "you should be doing this anyway" appears. :) [15:40] and it does say that it's windows users right now [15:40] so meh :P [15:45] Well, once Bookie gains traction we'll need to make sure those Windows Users are well-taken-care-of. :) [16:05] juju is cloud orchestration? [16:15] jrwren: that's the idea [16:52] i think why I don't "get it" is we have our own that is 6yrs old, and retrofitting ot juju would be a bit of work. [16:53] but maybe i'll start exploring that. [16:57] jrwren: yea, so juju is a LOT of work to get started if the charms don't exist yet. That's the hurdle I think we need to work on more [16:57] but if you're past that part, stuff like the recent bundle functionality starts to really show off [16:58] defined a whole working environment with 100+ services all setup/related/configured with options. [16:58] and import that into hp cloud, ec2, private openstack...and it really starts to show off it's usefulness imo [16:58] it's almost like sharing vagrant images for dev work in some ways [16:59] except, it's a dozen servers all setup/ready to go and you can bring it up, wait a bit, and start testing/hacking into it [17:00] that's the part I love to show, but I'm a dev so that's the cool part to me. Though I am working on a bookie charm and have a dream to get it all working so I can use it to run bmark.us and scale it up more, setup test beds, etc [17:01] jcastro: I kind of like that. a bunle is like a vagrant image for your deployment. [17:01] bundle that is [17:01] so it is a high barrier to entry. but that kind of makes snes. [17:01] for talking to devs that know wtf vagrant is at least [17:01] *sense [17:02] jrwren: yea, but I think there's room to make that better. [17:02] so the new bundle stuff lets you span environments? [17:02] jrwren: so it's high now, but still early enough, and we're working hard to get a lot of charms into shape so that you're at least part way there [17:02] jrwren: no, not currently. You can 'dupe' a bundle into any environment [17:03] its a tough problem to solve, espeically for the general case. [17:03] so you can go do comingsoon.jujucharms.com (total fake/virtual environment) and build a set of services, build relations, set config values, and then export that to a bundle file [17:03] but I'm starting to see the problem better, I think. [17:03] then take that bundle file to ec2, and use juju quickstart mybundle.yaml [17:03] and it'll dupe that entire setup, each machine, configuration parameter, relations built, and do it live in ec2 [17:03] and then juju switch hpcloud [17:03] yeah, that sounds really great. [17:03] and quickstart again and get that same exact setup [17:03] especially with a lot of cross dependency [17:04] right, so that's where the 'cloud orchastration' comes into play [17:04] does juju or its charms solve the problem of say... stateless postgresql servers or migration at all? [17:04] if the charms are done right then you abstract away the cloud layer [17:04] jrwren: so that's the charms job right? [17:04] e.g., so I have this production postgresql, now I want to move it from ec2 to rackspace... [17:04] yeah, I guess that is the charms job, adn that is *hard* [17:05] so our postgres charm has config params for a static volume so you can bring it up and then configure it to use a specific mount (EBS volume for instance) as the data for the service [17:05] and the charm takes config for locations to do backups, etc [17:05] ah, that is good. [17:05] http://comingsoon.jujucharms.com/sidebar/search/precise/postgresql-50/?text=postgresql#bws-configuration [17:05] is the vision to have many different postgresql charms, or a single charm with many params? [17:06] so you can look at the charm there's params for the backup dir, schedule, number to keep, etc [17:06] e.g. for our small cases we use ephemeral store and restore from backup on instance start [17:06] I'm not sure on that. On the one hand, the charm can be flexible and should use same defaults [17:06] but anyone can fork a charm, tweak it, and publish it again [17:06] right. [17:06] the hope would be that collaboration would ensure to get feature improvements into a single approved/reviewed charm that's trusted and powerful [17:07] almost like a small software package in ubuntu. You can fork mutt, but ideally you'd contribute back to mutt for everyone [17:07] I'm just wondering what is envisioned. Is it lots of forked charms? or is it single charms which many options? [17:07] so there are a lot of forked chams, but we've got the "recomended" which are vetted by a team and they show up more promiently in searches/etc [17:08] right, or even if I don't fork mutt, I might dislike a packaging option and repackage it. So will there be lots of re-charms? [17:08] yea, but only one is allowed to be recommended. [17:08] so if you want everyone to see it, to trust it, there will have to be work to find a path [17:08] just like there's only one mutt package in ubuntu [17:08] I guess I should look at charms conventions more. the debian/ubuntu packages analogy is interesting becuase there is much config in /etc/whatever.conf and /etc/defaults/whatever and even /etc/init/whatever... [17:09] now maybe you prove the more awesome charm and it's moved over. [17:09] and becomes the recommended/vetted option [17:09] is there a way to share/trade charm configs? [17:09] yea, it really is. A charm is basically all the debian wrappings [17:09] hmm, not following that 100% [17:09] e.g. can I use the recommended charm, but say "with these options"? [17:10] so each charm has a config.yaml that defines the available parameters [17:10] oh yea, that's what bundles do. You deploy something, configure it, and export it [17:10] so it deploys the original charm first, then applies your state over it [17:10] think of it like apt-get installing mysql, and then pasting over your mysql.cnf overrides [17:11] so in the debian world you might use a meta package with a post-install script to update the config on apt-get install jrwens-mysql [17:11] perfect. I get it. [17:11] the charm just has to be written well enough to have the right configuration parameters. [17:11] right, it all relies on the charms [17:11] I'm looking at the postgresql configuration parameters and they look extensive [17:11] yea, that's gotten a lot of time since we're a heavy pgsql shop [17:12] our own IS folks have spent time making these charms work for our real-world deployments [17:12] all our stuff is done using charms right now, so if you hit a service we use, the charms will usually be decent [17:12] there is even volume-ephemeral-storage right there in that charm already. that is great! [17:12] for instance, we're going to need encrypted disk (at rest) mongodb so our IS folks are going to add support [17:12] cool [17:12] exactly, *if* the work is done then it saves you a TON of time [17:13] it's just not always done already :) go community go :) [17:13] and if it isn't, you charm writting isn't too bad. [17:13] no, but it needs some love still [17:13] especially starting from scratch [17:13] i think our adoption will be slow, becuase cloud-init alone does 99% of what we need. [17:13] but we're working on it [17:13] cool [17:14] and this is a fundamental enough change for us that I don't think we are ready for it just yet. [17:14] but maybe in a year :) [17:14] heh, yea keep it in mind [17:14] tinker with it [17:14] I love the temp/dev environment story. I've found that so awesome the last year [17:14] I hated getting our charms going, but once they were up they've really allows some really cool stuff [17:15] make a config param the branch url for the app and it makes 'deploy my test branch for me to really tinker with' amazingly easy [17:15] alright. thanks. that really helps fill in some gaps. [17:15] or things like making a web app have a flag for debug mode vs prod mode and debug the live site with uncompressed js and such at the flip of a juju set comand [17:16] cool, let me know if you have any questions/etc. I think I understand it now myself. Just took a while [17:16] right [17:16] I did that by turning our cloud-config's into jinja templates and we just check a template variable for dev/prod :) [17:17] yep, I mean at fist my bookie charm is just "apt-get install XX, git clone yy, make install, open-port for traffic https://github.com/bookieio/bookie-charm/blob/start-config/hooks/install [17:17] make files ftw lol [17:18] :) [17:18] I do love me some Make [17:18] hehe, this looks A LOT like our cloud-config in concept. [17:18] err... not concept... in practice. [17:19] e.g. useing apt-get where you can, using pip where you can't use apt-get. [17:19] apt-get install pip ; pip install uwsgi [17:19] :) [17:19] at first I was a little hesitant to system install uwsgi that way, but its worked well. [17:20] although I did backport uwsgi 1.9 to precise, I need to come back to trying to use it. [17:35] jrwren: yea, I did that just because I'm working on getting it to run with uwsgi + upstart in this branch [17:35] so it's more about running the app in production to get uwsgi [17:35] jrwren: but yea, it's a isolated machine. Install system-wide, who cares. Tear it down/reset it back up [19:37] alright! weechat running inside tmux on a digital ocean box [19:38] hopefully no more join/part problems [19:40] nice. [19:40] awesome! [19:41] though any join/part problems you've had hasn't been bugging me, because of weechat's smart join/part/quit filter [19:41] did you find that buffer.pl plugin? [19:41] waf: cool [19:42] i've been off and on because i keep mucking with circ on chrome [19:43] waf: I left a new irc client that I was using at work open over night. it kept disconnecting/connecting every 15 minutes when it went to sleep :/ [19:45] yeah, I haven't tried to install any plugins for it yet though. that's next :) [23:05] shout-out to canonical in the top comment https://news.ycombinator.com/item?id=6705752