FastCGI Environment Changes for Rails - Updated
Recently we’ve made changes to FastCGI to disallow any environment except for Production when using Rails. This was brought on by some issues with the Development environment causing the quality of service to degrade. If you need to run your application in Development mode, please use your local machine for this. If you have a live application that was running in Development mode and now it doesn’t work, this is most likely the cause. You can correct this by making sure you have setup your database.yml file to have the proper MySQL connection information for Production, and that you’ve changed your environment.rb file to reflect these changes.
Update: I’m sorry, my first post isn’t entirely accurate. We are not disallowing any environment except for Production. We’re simply defaulting Rails installations to Production instead of their old default which was Development. This doesn’t mean we allow development on our servers, and in fact, we frown upon any development on our production servers because of the risk involved. I understand some people are concerned about staging, and this should be fine, so long as you use CGI instead of FastCGI.
.
March 14th, 2008 at 2:31 pm
Good job.
March 14th, 2008 at 2:49 pm
Perhaps this could have had an e-mail warning sent out, say, a week in advance to give people a chance to move over any problem applications?
March 14th, 2008 at 4:48 pm
Aikon — so, what do the other people using those shared servers and suffering from performance problems do during that week? Remember that the resources on DreamHost’s servers are shared. While I can sympathize with the headache you are no doubt having from a development environment being yanked away without notice, sharing also means being a good citizen with those CPU cycles. DreamHost found the source of a performance problem and dealt with it swiftly and that’s exactly what I want to see from my web host.
March 14th, 2008 at 5:12 pm
Great idea, I’ve also see this approach taken by other Rails Hosting companies.
March 15th, 2008 at 4:29 am
I wonder if this affected anything else. I’m in production mode, but my application had nearly 200 exception notifications sent overnight. All of them say “Expected (my controller filename) to define (my controller name)”. That file is present and the controller is defined in it. It’s working fine this morning and I haven’t made any changes.
March 15th, 2008 at 8:24 am
While I don’t think rails applications should have EVER been allowed to run in development mode on DH, we should have been given sufficient time (ie. a week or two) to test our applications. It is bad practice to just go changing the production server environment on your customers, especially because there are often undesired side effects. How long has DH offered rails hosting (years?) ? Why not wait one more week?
Based on my current server load, I’d say DH has other priorities anyway:
[evian]$ uptime
09:20:35 up 24 days, 16:54, 2 users, load average: 14.72, 22.94, 29.99
March 15th, 2008 at 7:38 pm
Maybe you shouldn’t use Rails period. You spend 80% of your time solving stupid performance problems.
March 16th, 2008 at 9:37 am
Mike Boone: I had the same errors you had and had to restart dispatch and all was well. Thanks once again for killing sites and throwing away our customers, DreamHost.
March 16th, 2008 at 1:59 pm
Thanks for fixing this issue.
March 17th, 2008 at 1:16 am
No, see, if you were running in DEV mode on a production site, you’re dumb. You get no warning. If you were running DEV mode on a DEV site, moving it to a local DEV box won’t kill you because, hey, it wasn’t live! And everyone else gets snappy sites again. Go bitch about downtime and how you’re losing billions.
March 17th, 2008 at 7:57 am
Thank you, you just successfully blocked staging sites. The purpose of a staging site is to get feedback from testers and ensures it works in an environment close to production.
How about low band width developers who can’t run
That you made this change without prior warning shows your contempt for rails developers. Couldn’t you have considered other options like throttling?
Thanks dreamhost!
March 17th, 2008 at 11:47 am
Hey guys,
this IS something you need to send mails out to at least all those people who are actually using rails! I don’t mind testing my app in production instead of development, but IT IS NOT NICE even for people who are testing it to suddenly see a broken app.
Like I said: Let people know a day or two before you do stuff like that!
March 17th, 2008 at 1:17 pm
I’d have to second @Bart here. Everyone seems to be discussing this (especially the OP) as if dev and production were the only options. Where, exactly, are we supposed to host staging environments?
March 17th, 2008 at 2:12 pm
Wow. I had to come here to figure it out.
I wondered wtf was going on. Lovely. Even though my dev is behind passwords so only a few people can access it. I’d have to second @Bart as well in that if you run dev in a production mode for testing purposes and only avail to a few users this should be allowable.
Oh well, at least I can hack around this latest adjustment.
March 17th, 2008 at 9:54 pm
How about you host a copy in production mode, then make changes in your local repo and sync them, like the rest of us?
April 7th, 2008 at 5:45 pm
Sending out an email might have been difficult to get all the users but I warning here would have helped.