| cmaloney | http://www.calm.com/ | 00:44 |
|---|---|---|
| greg-g | cmaloney: kinda neat | 01:01 |
| greg-g | the guided sessions is a good idea | 01:01 |
| 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:03 |
| greg-g | alright, pizza time | 01:04 |
| greg-g | laters! | 01:04 |
| cmaloney | Laterness. | 01:12 |
| rick_h_ | greg-g: lol | 01:20 |
| jrwren | good morning | 15:08 |
| rick_h_ | morning | 15:22 |
| cmaloney | Good morning | 15:23 |
| 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:24 |
| 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:25 |
| cmaloney | https://bmark.us/bmark/readable/b14779371a9beb | 15:30 |
| rick_h_ | performance reviews? | 15:34 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| cmaloney | Well, once Bookie gains traction we'll need to make sure those Windows Users are well-taken-care-of. :) | 15:45 |
| jrwren | juju is cloud orchestration? | 16:05 |
| rick_h_ | jrwren: that's the idea | 16:15 |
| 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:52 |
| jrwren | but maybe i'll start exploring that. | 16:53 |
| 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:57 |
| 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:58 |
| 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 | 16:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| jrwren | although I did backport uwsgi 1.9 to precise, I need to come back to trying to use it. | 17:20 |
| 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 | 17:35 |
| trevlar | alright! weechat running inside tmux on a digital ocean box | 19:37 |
| trevlar | hopefully no more join/part problems | 19:38 |
| gamerchick02 | nice. | 19:40 |
| waf | awesome! | 19:40 |
| 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:41 |
| gamerchick02 | i've been off and on because i keep mucking with circ on chrome | 19:42 |
| 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:43 |
| trevlar | yeah, I haven't tried to install any plugins for it yet though. that's next :) | 19:45 |
| trevlar | shout-out to canonical in the top comment https://news.ycombinator.com/item?id=6705752 | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!