| 00:14.11 | *** join/#uphpu KingMichael (~KingMicha@c-67-177-40-132.hsd1.ut.comcast.net) |
| 03:15.02 | *** join/#uphpu eggyknap (~jtolley@184-11-47-86.dr01.dlta.ut.frontiernet.net) |
| 03:15.02 | *** join/#uphpu eggyknap (~jtolley@unaffiliated/eggyknap) |
| 03:15.02 | *** mode/#UPHPU [+v eggyknap] by ChanServ |
| 04:42.52 | *** join/#uphpu UtahDave (~boucha@166.78.185.108) |
| 04:42.52 | *** mode/#UPHPU [+o UtahDave] by ChanServ |
| 05:49.20 | *** join/#uphpu UtahDave (~boucha@58.64.222.241) |
| 05:49.20 | *** mode/#UPHPU [+o UtahDave] by ChanServ |
| 06:06.40 | *** join/#uphpu UtahDave (~boucha@166.78.185.108) |
| 06:06.40 | *** mode/#UPHPU [+o UtahDave] by ChanServ |
| 07:26.19 | *** join/#uphpu mgeary (~mgeary@APuteaux-651-1-130-44.w86-217.abo.wanadoo.fr) |
| 07:26.19 | *** mode/#UPHPU [+v mgeary] by ChanServ |
| 13:16.52 | *** join/#uphpu eggyknap (~jtolley@184-11-47-86.dr01.dlta.ut.frontiernet.net) |
| 13:16.52 | *** join/#uphpu eggyknap (~jtolley@unaffiliated/eggyknap) |
| 13:16.52 | *** mode/#UPHPU [+v eggyknap] by ChanServ |
| 13:51.34 | *** join/#uphpu jnbek (~jnbek@pdpc/supporter/active/jnbek) |
| 13:51.35 | *** mode/#UPHPU [+v jnbek] by ChanServ |
| 14:53.17 | *** join/#uphpu UtahDave (~boucha@113.28.134.1) |
| 14:53.17 | *** mode/#UPHPU [+o UtahDave] by ChanServ |
| 15:13.42 | *** join/#uphpu josephscott (~josephsco@proxy.iad.automattic.com) |
| 15:22.16 | *** join/#uphpu MikeHansenMe (~mike@2001:558:6008:1f:50a4:11b1:681f:9c4b) |
| 15:25.38 | *** join/#uphpu benbankes (~ben@c-71-199-30-112.hsd1.ut.comcast.net) |
| 15:26.53 | *** join/#uphpu benbankes_ (~ben@c-71-199-30-112.hsd1.ut.comcast.net) |
| 15:35.47 | utahcon | Anyone want to discuss syncing servers via git vs rsync? |
| 15:36.15 | utahcon | Right now I have "farms" of servers that have a "pusher". I update the pusher via git and then use rsync to move files around. |
| 15:36.32 | utahcon | I was wondering if it would be better to just use git on each of the servers, and have them update via salt. |
| 15:51.00 | *** join/#uphpu SunSparc (~jonathan@69-27-175-74.acedatacenter.com) |
| 15:51.00 | *** mode/#UPHPU [+v SunSparc] by ChanServ |
| 15:55.43 | *** join/#uphpu mgeary (~mgeary@APuteaux-651-1-130-44.w86-217.abo.wanadoo.fr) |
| 15:55.44 | *** mode/#UPHPU [+v mgeary] by ChanServ |
| 15:56.41 | *** join/#uphpu kendsnyder (~kendsnyde@67.214.245.39) |
| 15:56.41 | *** mode/#UPHPU [+v kendsnyder] by ChanServ |
| 15:59.15 | tierra | I'd say it still depends heavily on your deployment setup either way... with git, you're pulling in the entire repository and it's history on a server that likely will never need it - though that rarely matters for most people |
| 15:59.24 | ninnypants | http://www.informationisbeautiful.net/visualizations/million-lines-of-code/ |
| 16:00.54 | tierra | most git-based deployment tools will check out your specific commit in a new directory entirely, which can be better for flipping the switch in a way that's instantaneous (changing the symlink for docroot), but that can be configured that way with rsync too |
| 16:01.49 | tierra | better for instantaneous updates, but also for rollbacks |
| 16:02.58 | *** join/#uphpu littleSkinner (~JSkinn@asa-2.fbp.ore.fiber.net) |
| 16:03.33 | tierra | however, also consider too that all of that can be made entirely pointless depending on your provisioning system... launching new web workers on new servers via salt/puppet/whatever and dynamically adding/removing from the load balancer can account for all of that on it's own too |
| 16:10.32 | *** join/#uphpu clintberry (~clintberr@75-148-102-17-Utah.hfc.comcastbusiness.net) |
| 16:10.32 | *** mode/#UPHPU [+v clintberry] by ChanServ |
| 16:11.44 | tierra | ninnypants: nice additions of healthcare.gov entries there |
| 16:22.09 | *** join/#uphpu supernovia (~Adium@66.219.200.107.provo.dynamic.broadweavenetworks.net) |
| 16:22.11 | *** mode/#UPHPU [+v supernovia] by ChanServ |
| 16:31.34 | ninnypants | tierra: yeah I'm not sure I've heard the 500M lines number but I wouldn't be surprised if it was reported at that |
| 16:44.56 | *** join/#uphpu undertakingyou (~undertaki@67.214.250.163) |
| 16:44.56 | *** mode/#UPHPU [+v undertakingyou] by ChanServ |
| 16:48.12 | carmony | now I'd recommend having all your servers point to an internal git server that you control |
| 16:48.43 | herlo | the value of that is good, but git's performance is not as good as rsync when it comes to pure data transfer. |
| 16:49.09 | herlo | but not sure performance is an issue with php, it is when you have a lot of binaries though. |
| 16:50.32 | *** join/#uphpu benbankes (~ben@50-200-100-242-static.hfc.comcastbusiness.net) |
| 16:53.34 | tierra | That performance only matters if you use in-place updates though, which neither rsync or git deployment forces you to do. I wouldn't necessarily make that a determining factor |
| 16:53.53 | herlo | nor would I |
| 16:54.26 | herlo | another thing you can do with both that is nice, but differ in the way you do them is having multiple deploy locations |
| 16:54.32 | herlo | with git, you can just switch a branch |
| 16:57.13 | *** join/#uphpu hallamigo (~hallamigo@75-145-59-129-Utah.hfc.comcastbusiness.net) |
| 16:58.29 | romanovic | tierra: out of curiousity, what git-based deployment tools do you use? |
| 17:00.12 | *** join/#uphpu jshultz (~jshultz@107.0.84.214) |
| 17:04.22 | *** join/#uphpu HumanCell (~Humancell@216.51.68.1) |
| 17:05.05 | tierra | I've used capistrano before, but like I said, that's a moot point depending on your configuration management system (I've also used Chef in the past) |
| 17:05.43 | herlo | right, and I've used puppet to deploy, too. Though I wouldn't recommend that approach. :) |
| 17:06.20 | tierra | I don't recommend Chef these days though - I used to think it was idealogically great in that you had the full power of a scripting language to write custom deployment cookbooks... now I just think it's overkill and makes the whole thing way too complicated |
| 17:06.33 | tierra | especially if your application isn't also ruby |
| 17:06.41 | HumanCell | SaltStack? |
| 17:07.33 | herlo | people use saltstack to deploy yes |
| 17:07.46 | herlo | I've heard good things about it, but I've personally not done it that way. |
| 17:08.09 | HumanCell | I missed the beginning of the thread ... what are you working to do? |
| 17:09.34 | HumanCell | I'm just learning SaltStack to automate a large AWS application that we are building. |
| 17:09.52 | HumanCell | I'm always wanting to learn from others experiences ... |
| 17:10.32 | tierra | utahcon was asking about git vs rsync deployment, but we were also discussing how much that actually might matter depending on your SCM |
| 17:11.33 | HumanCell | Ah ... yeah, we're using a hybrid approach of using Salt Stack for the base configuration installation and management, and then deploy from git/svn ... any of the code we wrote. |
| 17:33.36 | HumanCell | I hate conference websites that hide the cost of the event ... I'm sure it's here very obvious ... but can't seem to find it! http://www.cvent.com/events/saltconf-2014/event-summary-3aef0eba23dd49a1bd9ffcaaf83d657e.aspx |
| 17:37.06 | herlo | try registering |
| 17:37.50 | DexterTheDragon | it's in the first paragraph on the page |
| 17:38.14 | cro | In "register now" |
| 17:38.20 | HumanCell | AH!! |
| 17:38.39 | HumanCell | Silly me ... small fonts, and the expectation that I would click "Register" and find it ... |
| 17:38.39 | cro | Early bird ends at midnight tonigh |
| 17:39.14 | herlo | though I might 'go' |
| 17:39.54 | cro | herlo: it'll be good to see you |
| 17:40.04 | cro | did you submit a talk proposal? |
| 17:40.13 | herlo | no |
| 17:40.36 | HumanCell | Curious ... anyone know if there is any Salt integration into supervisord? |
| 17:40.52 | cro | HumanCell: yes |
| 17:41.15 | cro | HumanCell: http://docs.saltstack.com/ref/modules/all/salt.modules.supervisord.html?highlight=supervisord#salt.modules.supervisord |
| 17:42.23 | herlo | cro: do you work for SaltStack now too? :) |
| 17:42.28 | cro | :-) |
| 17:42.46 | cro | been here about 3 weeks |
| 17:44.34 | cro | Love HopeKids, just burned out. Couldn't pass up the chance to move back to tech. |
| 17:44.50 | HumanCell | cro: we were looking at using the RPC commands to adjust the count/number of processes of each type on the fly ... would that have to be done via the reload or restart in Salt? |
| 17:47.19 | cro | HumanCell: So rather than 'supervisorctl restart' at the command line for each machine, you'd do "salt '[minionmatch]' supervisord.restart [servicename]" |
| 17:47.26 | cro | did I understand you right? |
| 17:48.57 | HumanCell | One of my developers said that he believe that via the RPC interface he could adjust the count of processes in a way that would not require the restart. Maybe this is not the case. |
| 17:49.29 | SunSparc | ninnypants: Nice link. |
| 17:50.28 | cro | HumanCell: I've not used the supervisord RPC api, I'm looking at the docs |
| 17:50.54 | HumanCell | Our issue is looking for a way to manage large numbers of worker processes and scaling up and down on the fly without restarts. |
| 17:51.19 | HumanCell | Our workers have defined lifetimes, and when they die supervisor reincarnates them. |
| 17:52.06 | HumanCell | So our goal is to keep supervisor up to date with how many of each type of worker ought to be alive at any time. |
| 17:53.48 | cro | HumanCell: Yes, you could do that. You could either add some functionality to the supervisord salt module, or call modules.supervisord.custom with a command line that would adjust the parameters |
| 17:54.27 | HumanCell | Now Salt does not provide any Supervisor-like functionality does it? Processor monitoring/restarting? |
| 17:55.02 | cro | HumanCell: so if I understand right, you're not concerned about killing off workers since they have a defined lifetime? |
| 17:55.10 | HumanCell | yep |
| 17:55.51 | HumanCell | We're building a decentralized job/workflow service so we can monitor queue depths and know when we need more workers of different types. |
| 17:55.52 | cro | Salt itself doesn't take supervisor's place. It has the supervisord module to provide the integration. |
| 17:59.18 | HumanCell | So it does look like we ought to be able to use the "reload config" ... as long as it doesn't impact the running workers. |
| 18:00.50 | cro | HumanCell: Specifically 'reread' I think. |
| 18:02.10 | HumanCell | k ... it's on our roadmap to resolve in December ...so I've got more time to research. And I have a lot of more fundamental Salt to learn and implement. :-) |
| 18:15.55 | HumanCell | cro: here is one of the "real-time" config apps for supervisor ... this is more of what we were exploring ... https://github.com/mnaberez/supervisor_twiddler |
| 18:16.56 | cro | HumanCell: That's very helpful, let me digest a while |
| 18:17.03 | HumanCell | np |
| 18:17.38 | HumanCell | We found it here: https://github.com/Supervisor/supervisor/blob/master/PLUGINS.rst some good addons. |
| 18:23.50 | *** join/#uphpu undertakingyou (~undertaki@danix.eaerich.com) |
| 18:23.50 | *** mode/#UPHPU [+v undertakingyou] by ChanServ |
| 18:43.54 | josephscott | more court items to watch - http://www.wired.com/opinion/2013/11/so-the-internets-about-to-lose-its-net-neutrality/ |
| 18:55.01 | ninnypants | anyone know of a good country to state/province dataset for php? |
| 18:57.25 | DexterTheDragon | ninnypants: https://github.com/umpirsky/country-list |
| 19:06.34 | ninnypants | DexterTheDragon: thanks doesn't seem to do states though, but I did find this http://www.timdavis.com.au/data/ |
| 19:06.54 | ninnypants | seems to have the data I need I just have to convert to csv and parse |
| 19:07.04 | DexterTheDragon | ninnypants: looks like you can add states to it at the bottom of the readme |
| 19:29.41 | tierra | ninnypants: these guys are awesome for maintaining clean, well designed formats/structure even for the ISO 3166 data for free: http://www.geopostcodes.com/GeoPC_ISO_3166_2_Regions_codes |
| 19:30.34 | tierra | I never got around to it before the project flopped, but I was planning on replacing our crappy geo tables we had for Sold.com back in the day to use the data from these guys |
| 19:33.47 | tierra | they have awesome coverage for ZIPs in US and Canada, and generally better organized data with well thought out updates... better than ZipInfo imho |
| 19:34.03 | tierra | can't believe ZipInfo has been going for so long on their old site design |
| 19:35.35 | tierra | exact same design since 1998 - no joke |
| 19:35.38 | tierra | https://web.archive.org/web/19981201235540/http://www.zipinfo.com/ |
| 19:36.34 | tierra | ZipInfo is a pain in the.... |
| 19:36.35 | ninnypants | tierra: I think this is the best I've seen so far |
| 19:40.10 | tierra | my old company had a subscription for ZIPList Max or whatever the highest subscription is, so I've been all over in that data, and I'm not impressed... I'd pay more for that GeoPostcodes without *any* of that CBSA/MSA/Market Area crap you get with ZIPList that's entirely useless really |
| 19:41.53 | tierra | be sure to check out that "Reference tables" section in the sidebar on GeoPostcodes |
| 19:42.20 | tierra | they're all free tables for all the ISOs you'd ever use for that stuff |
| 19:49.39 | tierra | btw, supposedly MaxMind recommends http://www.geonames.org/ - which is CC-BY-3.0 (requires attribution) |
| 19:50.08 | tierra | for zips anyway |
| 19:50.50 | tierra | doesn't look like they have the ISO region data though |
| 20:15.32 | ninnypants | tierra DexterTheDragon here's what I ended up with https://github.com/ninnypants/countries-states |
| 21:17.02 | herlo | is anyone going to the 'Terms and Conditions' movie that Mozilla is putting on tomorrow? |
| 21:22.06 | ninnypants | herlo: haven't even heard about it |
| 21:26.32 | herlo | https://reps.mozilla.org/e/screening-of-terms-and-conditions-may-apply/ |
| 21:27.18 | herlo | I think there's still seats available |
| 21:27.19 | herlo | http://mozutah-es2.eventbrite.com/ |
| 21:27.44 | herlo | oh, it's sold out now |
| 21:28.53 | ninnypants | ah too bad it's right by me too |
| 21:30.45 | herlo | yeah. If I end up not being able to go, I'll send you my tickets |
| 21:30.54 | herlo | atm, I'm pretty sure I can go though. |
| 21:34.51 | carmony | ping josephscott |
| 21:35.25 | josephscott | carmony: howdy |
| 21:35.30 | carmony | josephscott: pm :) |
| 21:35.43 | josephscott | k |
| 21:46.04 | carmony | ping supernovia :) |
| 21:59.08 | *** join/#uphpu Benni_Hanna (~Benni_Han@neutroninteractive-xmission.xmission.com) |
| 22:28.24 | *** join/#uphpu KingMichael (~KingMicha@c-67-177-40-132.hsd1.ut.comcast.net) |
| 22:40.23 | mgeary | okay |
| 22:40.26 | mgeary | i'm just gonna say it |
| 22:40.50 | mgeary | who the HECK at Apple thought it would be an improvement to remove the playback progress bar in iTunes??!! |
| 22:40.54 | mgeary | really?! |
| 22:41.14 | mgeary | it's like there's an internal contest to see who can make iTunes crappier |
| 22:41.43 | mgeary | they're going to disable pause functionality next. "You started the song. Why would you want to pause it? Show some commitment!" |
| 22:45.59 | fungus | because that feature doesn't directly have anything to do with selling music/apps. |
| 22:48.20 | tierra | hah |
| 23:09.52 | supernovia | oh hey carmony |
| 23:09.55 | supernovia | you still around? |
| 23:18.05 | *** join/#uphpu kendsnyder (~kendsnyde@67.214.245.39) |
| 23:18.05 | *** mode/#UPHPU [+v kendsnyder] by ChanServ |
| 23:34.28 | ninnypants | supernovia: are you feeling better Kelly said it only lasted Saturday night? |
| 23:34.53 | supernovia | Yeah, I was OK-ish yesterday; much better today |
| 23:35.25 | ninnypants | Glad we didn't end up making you feel too horrible then |
| 23:50.57 | carmony | supernovia: I am now, you still around? :) |
| 23:51.14 | supernovia | Yeah I'm here |
| 23:51.23 | supernovia | and ninnypants no worries :) |
| 23:52.59 | supernovia | sup carmony? |
| 23:53.23 | carmony | supernovia: pm :) |
| 23:53.47 | supernovia | I don't see one .. hmmm |