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