solidsnack

Activity Graph

Page 1 of 1

2018-08-29

[01:19:20] solidsnack: *.net *.split

2018-08-10

[19:54:47] solidsnack: Ping timeout: 245 seconds
[19:56:22] solidsnack: has joined #ruby

2018-07-23

[15:19:21] solidsnack: Ping timeout: 256 seconds
[15:22:00] solidsnack: has joined #ruby
[15:23:27] solidsnack: has joined #ruby
[15:23:27] solidsnack: Changing host

2018-07-20

[00:07:22] solidsnack: *.net *.split
[00:15:47] solidsnack: has joined #ruby

2018-06-20

[03:51:09] solidsnack: Ping timeout: 276 seconds
[05:27:01] solidsnack: has joined #ruby
[05:58:33] solidsnack: Ping timeout: 276 seconds
[06:20:29] solidsnack: has joined #ruby

2018-06-01

[03:44:47] solidsnack: *.net *.split
[07:47:36] solidsnack: has joined #ruby

2018-05-29

[02:47:14] solidsnack: *.net *.split
[02:48:02] solidsnack: has joined #ruby

2018-05-19

[15:33:50] solidsnack: Remote host closed the connection
[15:37:45] solidsnack: has joined #ruby

2018-05-06

[11:25:44] solidsnack: has joined #ruby

2018-05-04

[05:15:43] solidsnack: *.net *.split
[05:16:11] solidsnack: has joined #ruby

2018-04-25

[12:25:53] solidsnack: *.net *.split
[12:27:19] solidsnack: has joined #ruby
[15:01:24] solidsnack: *.net *.split
[15:03:18] solidsnack: has joined #ruby

2018-04-11

[20:28:33] solidsnack: *.net *.split

2018-03-02

[04:11:06] solidsnack: Read error: Connection reset by peer
[04:18:40] solidsnack: has joined #ruby

2018-02-23

[07:53:25] solidsnack: has joined #ruby
[08:11:50] solidsnack: *.net *.split
[08:22:39] solidsnack: has joined #ruby

2018-02-22

[13:15:44] solidsnack: Ping timeout: 255 seconds
[13:18:44] solidsnack: has joined #ruby

2018-02-09

[22:31:53] solidsnack: has joined #ruby

2018-01-18

[03:30:05] solidsnack: *.net *.split
[03:31:57] solidsnack: has joined #ruby

2017-12-27

[19:12:53] solidsnack: Ping timeout: 252 seconds
[19:45:47] solidsnack: has joined #ruby

2017-12-01

[02:28:56] solidsnack: has joined #ruby

2017-11-08

[09:43:36] solidsnack: *.net *.split
[09:49:07] solidsnack: has joined #ruby

2017-10-16

[06:26:58] solidsnack: has joined #ruby

2017-09-11

[20:24:08] solidsnack: *.net *.split

2017-09-04

[18:38:25] solidsnack: *.net *.split

2017-08-14

[23:51:23] solidsnack: *.net *.split
[23:56:33] solidsnack: has joined #ruby

2017-07-16

[03:58:38] solidsnack: Ping timeout: 255 seconds
[22:20:01] solidsnack: has joined #ruby

2017-06-20

[00:17:18] solidsnack: *.net *.split

2017-05-11

[13:22:57] solidsnack: has joined #ruby

2017-05-02

[14:43:35] solidsnack: Ping timeout: 264 seconds
[14:50:12] solidsnack: has joined #ruby

2015-05-05

[19:48:00] solidsnack: Is it safe to run `rake db:migrate` from hundreds of servers simultaneously?
[19:49:04] solidsnack: Like, on startup they run it.
[19:51:30] solidsnack: Say we have one hundred Rails servers. They are started with Upstart. In rails.conf we have: `rake db:migrate && rails s`
[19:51:53] solidsnack: bricker: Can you tell me more about that?
[19:53:26] solidsnack: Well, the reason to do it is pretty simple: it simplifies deployment.
[19:53:57] solidsnack: It removes the need for a single magic/master server that runs special startup code when a new version is released.
[19:54:15] solidsnack: Rails roles?
[19:54:39] solidsnack: Not in an Auto-Scaling Group...
[19:56:20] solidsnack: If you use CodeDeploy and deploy to an autoscaling group...
[19:56:24] solidsnack: ...you don't have roles.
[19:57:37] solidsnack: rhizome: Amazon product
[19:58:18] solidsnack: It drops code on autoscaling groups and has a web panel, saying whether the scripts exited 0 or not.
[19:59:25] solidsnack: batasrki: Where else would you run the code?
[19:59:55] solidsnack: rhizome: Try shutting your laptop during that.
[20:00:31] solidsnack: rhizome: The code doesn't actually run on the for a migration. It could run on a developer's laptop, or during a build.
[20:01:09] solidsnack: s/run on the/run on the DB
[20:01:53] solidsnack: It's a hundred servers for one Rails app.
[20:02:40] solidsnack: batasrki: Unicorn.
[20:03:03] solidsnack: batasrki: Yes.
[20:03:48] solidsnack: batasrki: I just wanted to be clear, I didn't mean 100 distinct Rails apps with different code bases.
[20:04:25] solidsnack: I meant one codebase, running 100 times.
[20:04:56] solidsnack: tubbo: This is a very non-cloud way to deploy :(
[20:05:23] solidsnack: That is a very non-cloud way, too.
[20:05:44] solidsnack: What a channel.
[20:07:32] solidsnack: tubbo: We it doesn't work that way.
[20:07:57] solidsnack: 100 Rails apps can't really generate enough transactions for one database.
[20:10:16] solidsnack: All I'm saying is: in cloud, we drop the code on the servers, configure which database to use, and walk away.
[20:11:14] solidsnack: batasrki: Maybe there needs to be a plugin or something?
[20:11:23] solidsnack: RakeLockingMigration?
[20:12:53] solidsnack: batarski: We have one very big database.
[20:12:58] solidsnack: Not 100 litte ones.
[20:13:47] solidsnack: You wouldn't believe how right you are...
[20:14:59] solidsnack: batasrki: In general, yes; but if you have one of these and treat the rest as non-special and disposable, you have a tractable problem.
[20:15:09] solidsnack: Since that one special node is the database...