Imminent Death of the Heroku Google Group
fIn the latest Heroku Newsletter[1], it says this group will be killed at the end of April, and suggests instead to go to support.heroku.com (which is private) or stackoverflow.com. While SO is awesome, is it really an adequate replacement for this group? I've found that SO is a great complement to mailing lists but doesn't allow for the same kind of deep discussion and community building. Worse, it requires active attention rather than arriving in one's inbox, so the people who are most likely to have an answer to a question are the least likely to hear it -- since they're not having any problems. Why uproot a productive community (this mailing list) and hope that it migrates to a new place with a radically different interaction model? [1] http://lists.heroku.com/t/ViewEmail/r/6DFC781E555FD71E/CEC5941F8B0A6F4BC5EC08CADFFC107B -- Alex Chaffee - a...@stinky.com http://alexchaffee.com http://twitter.com/alexch -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en
Re: Background job guidance
I rolled my own background job processor using CouchDB. Procfiles and Foreman and the Cedar process model make it very simple. I can even scale up and down using the Heroku API from inside a running Heroku web process; I think the Resque systems I saw described don't allow you to scale down to 0 workers but mine does. Check the code at https://github.com/alexch/sharebro, especially https://github.com/alexch/sharebro/blob/master/spec/ant_spec.rb https://github.com/alexch/sharebro/blob/master/lib/ant.rb https://github.com/alexch/sharebro/blob/master/work.rb If anyone's interested I could collaborate on pulling it out into yet another gem, but for now it's stuck in this app (and a couple other private ones). For an arguably better system see http://blog.leshill.org/blog/2011/04/03/using-resque-and-resque-scheduler-on-heroku.html https://github.com/ajmurmann/resque-heroku-autoscaler but I didn't want to add Redis and Resque -- I prefer the devil I know cause I created him :-) - A -- You received this message because you are subscribed to the Google Groups Heroku group. To view this discussion on the web visit https://groups.google.com/d/msg/heroku/-/M48-ZnFTvG8J. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
[ANN] rerun 0.6.3 released, with foreman/Procfile support
rerun 0.6.3 released http://github.com/alexch/rerun == Description: Rerun launches your program, then watches the filesystem. If a relevant filechanges, then it restarts your program. Rerun works for both long-running processes (e.g. apps) and short-running ones(e.g. tests). So it works like shotgun and autotest (and guard and all therest). Rerun's advantage is its simple design. Since it uses standard Unix SIGINTand SIGKILL signals, you're sure the restarted app is really acting justlike it was when you ran it from the command line the first time. == New features: * better signal handling * support for foreman and Heroku Cedar apps (And hey, does Shotgun reload your Worker processes if you're using Foreman and a Procfile? I don't think it does...) * On-The-Fly Commands While the app is (re)running, you can make things happen by pressing keys: r - restart (as if a file had changed) c - clear the screen x - exit (just like control-C) -- Alex Chaffee - a...@stinky.com http://alexchaffee.com http://twitter.com/alexch -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
How can I scale my worker processes from inside a web process?
(was Can I issue a heroku restart from within my app that's running on Heroku) Neil, you read my mind! Thanks for the answer. My only regret is that it's buried in a thread with advice for some poor soul who wants to use heroku:restart. Oh wait, I can rename the thread! :-) How about How can I call the Heroku API from inside my Heroku app? or How can I have my web process scale up and scale down my worker process? I want to do this in response to a web request, so I don't have to pay for my worker process being awake 24/7. Here's what I got: # Gemfile gem 'heroku' # unix command line heroku config:add HEROKU_APP_NAME=myapp \ HEROKU_EMAIL=m...@example.com \ HEROKU_PASSWORD=secret # ruby require 'heroku' heroku = Heroku::Client.new(ENV[HEROKU_EMAIL], ENV[HEROKU_PASSWORD]) heroku.ps_scale(ENV[HEROKU_APP_NAME], :type = worker, :qty = 1) If you don't want your app to be able to access all your other apps -- maybe you're on a team of untrustworthy rapscallions -- then sign up for a new heroku account with a new email address and password, and then add that heroku account as a collaborator. I can point you to github source once I'm sure it all works in my latest app. - A P.S. Thanks to https://github.com/pcapr/dyno-blitzer/issues/3 for deciphering the 422 error. -- You received this message because you are subscribed to the Google Groups Heroku group. To view this discussion on the web visit https://groups.google.com/d/msg/heroku/-/Ns6_CvJ4yHIJ. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Deploying an app on behalf of a third party
Dear Heroku - I've developed a set of test-first ruby training exercises at http://testfirst.org and I've been brainstorming about how to take it to the next level. I've been imagining an interactive web site, where users can edit code and run RSpec tests from inside their web browser. Unfortunately (for me and for the whole world) the SCRIPT tag only supports JavaScript on most browsers. So I'd have to send the students' code to a web server and execute it there. The problem with that is security. The code is all open source and I won't be storing any sensitive information, so I'm not worried about malicious crackers[1], but there's still a risk that a student could, accidentally or on purpose, break or otherwise compromise the functionality of the app if I'm evaling arbitrary code on their behalf. I know about $SAFE but I don't think it's actually safe enough for this purpose. I've also heard of Why's Freaky Sandbox but I couldn't find the code anywhere (R.I.P.) So I had a thought: what if I have a master app, and a student could connect to it, temporarily give me his Heroku credentials, and then I could spin up a lab app under his Heroku account that only he knows the URL to. Anything he breaks would just affect his own instance, and I could have a big reset button that could clean up (heroku restart) after that. I'd still use $SAFE to stop access to the filesystem, but even that wouldn't be very risky. Is there a way to do this cleanly? Say, with a Heroku OAuth API? Oh, wait, I think I just figured it out! I can't create an app with the user's credentials. But I can create an app with *my* credentials (SSH keys) and then transfer ownership to the user (after appropriate email validation, of course). So I guess now my question becomes, can I use the heroku gem or CLI from inside a running heroku app? - A [1] not nearly as tasty as Animal Crackers. (cc'ing the test-first-teaching google group in case someone there has any bright ideas or wants to contribute) -- Alex Chaffee - a...@stinky.com - http://alexch.github.com Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch | http://alexch.tumblr.com -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Anyone having trouble using heroku console?
Rake 0.9.x no longer includes the DSL module in the top level namespace. So another solution to the uninitialized constant Rake::DSL problem is to explicitly include the DSL module in your Rakefile, near the top, like this: require rake include Rake::DSL It's more or less fixed now (with Rake 0.9.2 and Rails 3.0.9) but it's been a total clusterfrack and a great example of a poor release process. On Jul 14, 10:53 am, Terence Lee tere...@heroku.com wrote: Hello Keenan, It's because rake is built into ruby 1.9.2 and the version is 0.8.7 and that's the one being called here. We're looking into ways to fix this. In the meantime, can you try hard coding your rake to 0.8.7 in your Gemfile? Once you have that working locally, it should work fine on heroku. Best, Terence On Wed, Jul 13, 2011 at 9:06 AM, Keenan Brock kee...@thebrocks.net wrote: Hi, Question: Are others able to run: heroku rake db:migrate OR heroku console puts Model.count ? This is probably user error, but I can't figure it out. reminds me of not specifying RAILS_ENV when running rails console. I had run rake db:seed which populated the Avatar model. I view a page on the website that relies upon the Avatar model. I ran heroku config:add RAILS_ENV=production (just in case) But from heroku console: * puts Avatar.count* ActiveRecord::StatementInvalid: PGError: ERROR: relation avatars does not exist : SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum WHERE a.attrelid = 'avatars'::regclass AND a.attnum 0 AND NOT a.attisdropped ORDER BY a.attnum /app/.bundle/gems/ruby/1.9.1/gems/activerecord-3.0.9/lib/active_record/conn ection_adapters/abstract_adapter.rb:207:in `rescue in log' /app/.bundle/gems/ruby/1.9.1/gems/activerecord-3.0.9/lib/active_record/conn ection_adapters/abstract_adapter.rb:199:in `log' /app/.bundle/gems/ruby/1.9.1/gems/activerecord-3.0.9/lib/active_record/conn ection_adapters/postgresql_adapter.rb:501:in `query' /app/.bundle/gems/ruby/1.9.1/gems/activerecord-3.0.9/lib/active_record/conn ection_adapters/postgresql_adapter.rb:1037:in `column_definitions' * heroku rake db:migrate* (in /app) rake aborted! uninitialized constant Rake::DSL /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2482:in `const_missing' /app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:8:in `class:TaskLib' /app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:6:in `module:Rake' /app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:3:in `top (required)' /app/.bundle/gems/ruby/1.9.1/gems/rdoc-3.8/lib/rdoc/task.rb:37:in `require' /app/.bundle/gems/ruby/1.9.1/gems/rdoc-3.8/lib/rdoc/task.rb:37:in `top (required)' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks/documentat ion.rake:2:in `require' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks/documentat ion.rake:2:in `top (required)' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:15:in `load' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:15:in `block in top (required)' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:6:in `each' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:6:in `top (required)' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/application.rb:2 15:in `require' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/application.rb:2 15:in `initialize_tasks' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/application.rb:1 39:in `load_tasks' /app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/application.rb:7 7:in `method_missing' /app/Rakefile:7:in `top (required)' /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2373:in `load' /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2373:in `raw_load_rakefile' /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2007:in `block in load_rakefile' /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2058:in `standard_exception_handling' /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2006:in `load_rakefile' /usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:1991:in `run' /usr/ruby1.9.2/bin/rake:31:in `main' Thanks for any pointers on what I am doing wrong, Keenan --Keenan -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com. To unsubscribe from
Re: uninitialized constant Rake::DSL
YMMV, but I'm pretty sure Rake 0.9.2 fixes this.
Another solution is to add the following to your Rakefile, right after
require 'rake'
class Rails::Application
include Rake::DSL
end
(from memory; please let me know if it doesn't work and I'll look it
up for you)
On Jun 17, 7:01 pm, Daniel Myasnikov myasnikovdan...@gmail.com
wrote:
Hey
I had the same issue, and the whole yesterday to solve it.
First of all, if you are using Rake 0.8.7 and put require 'rake/
dsl_definition' it won't work for you. This feature was introduced
for Rake 0.9.x.
I strongly recommend to use Rake 0.8.7
and get rid out of everything that you put for rake 0.9.x, such as
'include Rake:dsl' and extend Rake::FileUtilsExt
So your RakeFile file should look like:
require File.expand_path('../config/application', __FILE__)
require 'rake'
MyApplicationName::Application.load_tasks
2. Secondly check if you have installed Rake 0.9.x and remove it from
your computer and use Rake 0.8.7, which you have to install before
using
3. Use gem rake, 0.8.7 in your GemFile just after source 'http://
rubygems.org'
4. Make sure your gem for rails is '3.0.9'
5. Some said that this gem also helped them gem 'sqlite3',
'1.3.3', :group = :development
Also don't forget about debugging your Heroku application using
'heroku logs'
Daniel Myasnikov
On Jun 18, 11:43 am, Karl threadh...@gmail.com wrote:
Using Rails 3.0.9 (3.0.7 too), which load rake 0.9.2 with bamboo-
mri-1.9.2, causes:
$ heroku rake db:migrate
rake aborted!
uninitialized constant Rake::DSL
/app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:8:in
`class:TaskLib'
/app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:6:in
`module:Rake'
/app/.bundle/gems/ruby/1.9.1/gems/rake-0.9.2/lib/rake/tasklib.rb:3:in
`top (required)'
/app/.bundle/gems/ruby/1.9.1/gems/rdoc-3.6.1/lib/rdoc/task.rb:37:in
`top (required)'
/app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks/
documentation.rake:2:in `top (required)'
/app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:
15:in `block in top (required)'
/app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:
6:in `each'
/app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/tasks.rb:
6:in `top (required)'
/app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/
application.rb:215:in `initialize_tasks'
/app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/
application.rb:139:in `load_tasks'
/app/.bundle/gems/ruby/1.9.1/gems/railties-3.0.9/lib/rails/
application.rb:77:in `method_missing'
/app/Rakefile:7:in `top (required)'
/usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2373:in `load'
/usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2373:in `raw_load_rakefile'
/usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2007:in `block in load_rakefile'
/usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2058:in
`standard_exception_handling'
/usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:2006:in `load_rakefile'
/usr/ruby1.9.2/lib/ruby/1.9.1/rake.rb:1991:in `run'
/usr/ruby1.9.2/bin/rake:31:in `main'
(in /app)
I had to add, before require 'rake':
# Rakefile
require 'rake/dsl_definition'
But I don't get this on my development machine. Why?
--
You received this message because you are subscribed to the Google Groups
Heroku group.
To post to this group, send email to heroku@googlegroups.com.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en.
Re: workers dying overnight
Update: I upgraded my stack to Ruby 1.9.1 and the crashes seem to have stopped. (Knock wood!) heroku stack:migrate bamboo-mri-1.9.1 On Jul 30, 10:28 am, Alex Chaffee ale...@gmail.com wrote: What a useful command! Thanks. Still, I don't know what I could be doing to cause DJ to crash. Doesn't it catch all exceptions raised by jobs? My jobs are just doing plain vanilla Ruby stuff... - A On Jul 29, 8:22 am, Dan Croak dcr...@thoughtbot.com wrote: Only time I've had issues with workers is when I messed up something on my side so that I was causing DJ to crash. I debugged it by doing: heroku ps On Thu, Jul 29, 2010 at 11:10 AM, Alex Chaffee a...@cohuman.com wrote: I wrote a simple Heroku app to do service monitoring. It uses DelayedJob to queue up repeating tasks like doing an HTTP ping of a server once a minute or once an hour. Twice now the worker has died overnight. heroku workers still says I'm running 1 worker, but there's no message in heroku logs -- not even the stub of logs from the DJ worker that was there before. It looks like the worker instance has been retired by the scheduler. If I run heroku workers 0; heroku workers 1 then it comes back and my jobs all start running. Aha! It just started up a worker on its own after I hit the web page for the first time today. I think the scheduler needs to be smarter about worker proceses... maybe it needs to check the database for any Delayed Jobs whose run_at is soon, and either not retire it or make sure a worker comes online in time to run it. The code is athttp://github.com/alexch/sentryifyou want to try it yourself. Has anyone else had this problem? -- Alex Chaffee - a...@cohuman.com -http://alexch.github.com Stalk me:http://friendfeed.com/alexch|http://twitter.com/alexch| http://alexch.tumblr.com -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: workers dying overnight
What a useful command! Thanks. Still, I don't know what I could be doing to cause DJ to crash. Doesn't it catch all exceptions raised by jobs? My jobs are just doing plain vanilla Ruby stuff... - A On Jul 29, 8:22 am, Dan Croak dcr...@thoughtbot.com wrote: Only time I've had issues with workers is when I messed up something on my side so that I was causing DJ to crash. I debugged it by doing: heroku ps On Thu, Jul 29, 2010 at 11:10 AM, Alex Chaffee a...@cohuman.com wrote: I wrote a simple Heroku app to do service monitoring. It uses DelayedJob to queue up repeating tasks like doing an HTTP ping of a server once a minute or once an hour. Twice now the worker has died overnight. heroku workers still says I'm running 1 worker, but there's no message in heroku logs -- not even the stub of logs from the DJ worker that was there before. It looks like the worker instance has been retired by the scheduler. If I run heroku workers 0; heroku workers 1 then it comes back and my jobs all start running. Aha! It just started up a worker on its own after I hit the web page for the first time today. I think the scheduler needs to be smarter about worker proceses... maybe it needs to check the database for any Delayed Jobs whose run_at is soon, and either not retire it or make sure a worker comes online in time to run it. The code is athttp://github.com/alexch/sentryif you want to try it yourself. Has anyone else had this problem? -- Alex Chaffee - a...@cohuman.com -http://alexch.github.com Stalk me:http://friendfeed.com/alexch|http://twitter.com/alexch| http://alexch.tumblr.com -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/heroku?hl=en. -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
workers dying overnight
I wrote a simple Heroku app to do service monitoring. It uses DelayedJob to queue up repeating tasks like doing an HTTP ping of a server once a minute or once an hour. Twice now the worker has died overnight. heroku workers still says I'm running 1 worker, but there's no message in heroku logs -- not even the stub of logs from the DJ worker that was there before. It looks like the worker instance has been retired by the scheduler. If I run heroku workers 0; heroku workers 1 then it comes back and my jobs all start running. Aha! It just started up a worker on its own after I hit the web page for the first time today. I think the scheduler needs to be smarter about worker proceses... maybe it needs to check the database for any Delayed Jobs whose run_at is soon, and either not retire it or make sure a worker comes online in time to run it. The code is at http://github.com/alexch/sentry if you want to try it yourself. Has anyone else had this problem? -- Alex Chaffee - a...@cohuman.com - http://alexch.github.com Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch | http://alexch.tumblr.com -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
problem (and solution) with migrating db twice
I've set up two Heroku instances, one for production and one for staging. When I deploy to staging I copy the production database over (using heroku db:pull followed by heroku db:push --app cohuman-staging) and run all migrations (using heroku rake db:migrate --app cohuman-staging). So far so good. Sometimes we don't want to push to production right away; we need to fix bugs or whatever on staging. But then we have to deploy to staging again. Here comes the problem: since I copy the production database again, I need to run migrations again. But if one of those migrations renames a table, I get a Postgres error: /usr/local/lib/ruby/gems/1.8/gems/activerecord-2.3.5/lib/active_record/connection_adapters/abstract_adapter.rb:219:in `log': An error has occurred, this and all later migrations canceled: (StandardError) PGError: ERROR: relation followings already exists : ALTER TABLE interests RENAME TO followings Apparently heroku db:push doesn't clear out the database first, so the old new table (if that makes sense) is still around. My solution was to add the following in my rename migration: def self.up execute DROP TABLE IF EXISTS followings rename_table :interests, :followings end It's kind of annoying, partly since this code is only necessary on staging, so it's needlessly complicating things when run on production... I'd be interested to hear if anyone has any cleaner solutions. For example, if I start using Heroku Bundles for backup, can I restore from my production backup to my staging database? (I admit I haven't used bundles yet and am sketchy on the details so feel free to RTFM me.) - Alex P.S. I've got a relatively clean rakefile for wrapping deploys to Heroku with things like grepping git logs and sending an email; let me know if anyone's interested and I'll post it in a gist or something. --- Alex Chaffee - a...@cohuman.com - http://alexch.github.com Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch | http://alexch.tumblr.com -- You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
Re: Site down between Push and Migrate?
Awesome. That's even better than I'd hoped! :-) - A On Aug 17, 12:00 pm, Adam Wiggins a...@heroku.com wrote: On Sun, Aug 16, 2009 at 10:39 AM, Alex Chaffeeale...@gmail.com wrote: During the few seconds the restart is happening, what happens to incoming HTTP requests? Are they queued or do they fail? If the latter, where's the error page and can we change it? And what's the timing like for applying the change to multiple dynos? Is it possible that one dyno is still running the old code while another is running the new code? Requests will always be going to one and only one revision of the code at a time. The sequence is like this: 1. You git push, which compiles a slug. 2. If successful, the slug is distributed to our dyno grid and dynos are started for the new slug. But no traffic is being sent to them yet - the routing mesh is routing all traffic to the dynos running the old slug. 3. Once all the new dynos are up and ready to receive connections, the routing mesh updates its routing table. Existing requests will complete on the old dynos, any new requests will be sent to the new ones. In summary, the switch is instantaneous and seamless, with no period of error pages or requests being routed to the wrong dyno. You can test this yourself by running a simple load test during a deploy. Something like: $ ab -c 1 -n 50http://myapp.heroku.com/| egrep '^(Complete|Failed)' $ git push heroku When I ran this I got the following output (after all the git push / heroku slug compile messages): Complete requests: 50 Failed requests: 0 Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en -~--~~~~--~~--~--~---
Re: Site down between Push and Migrate?
Ricardo - Thanks for the detailed replies but I'm still unclear on a few things about downtime during deploy. During the few seconds the restart is happening, what happens to incoming HTTP requests? Are they queued or do they fail? If the latter, where's the error page and can we change it? And what's the timing like for applying the change to multiple dynos? Is it possible that one dyno is still running the old code while another is running the new code? - Alex On Aug 13, 10:48 am, Ricardo Chimal, Jr. rica...@heroku.com wrote: running migrations before updating the code would still leave you in a similar broken state because the database schema has changed but your code has not been updated for it. Depending on how much has changed will be the severity of your brokenness. Keep in mind that this is still a small period of time we're talking about, seconds not minutes. We used to have it automatically call rake db:migrate but there are problems when the migrations themselves were broken. On Aug 13, 5:14 am, Chap c...@chap.otherinbox.com wrote: Good point Richard, if we have to handle it ourselves I think it deserves a little mention in the docs. I assume that most people are use to capistrano which had a cap deploy:migrations command that would run the migrations before symlinking the new code. (Although I never personally tested it.) Maybe heroku needs needs a similar command that would run the migrations before updating the code? On Aug 12, 3:22 pm, Ricardo Chimal, Jr. rica...@heroku.com wrote: This is going to be a problem wherever you deploy your application to. And what happens during that gap is really up to you. Once the push completes the old version of your codebase is no longer running. If the migration changes the database schema radically odds are you're going to see a lot of broken pages because presumably you have updated your code for those changes. If the migration does something minor, then you probably won't see a lot of breaking. The point being that handling this is left to you as the developer to handle. One option is to have a maintenance flag in your database or config var that you can toggle to display a maintenance page. This is probably the easiest to do and could be used for a large set of use cases. Another option would be to have code that can work around your schema changes, this is probably the most difficult for most to implement but it is an option. -- Ricardo On Aug 10, 5:40 am, Chap c...@chap.otherinbox.com wrote: Between the push to heroku (which will automatically launch the app) and heroku rake db:migrate what happens? I know it's only a few seconds, but potentially the site would be broke right? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en -~--~~~~--~~--~--~---
Re: .gems vs. geminstaller.yml
Is there a feature that Gem Installer offers that you wished you had for the gems manifest? Not yet... But I want to be able to have a single config file, not 2 or 3. Since geminstaller has nice features like rogue gem listing which may come in handy, I'd prefer that one. Or are you looking for standardization/interoperability with an existing community tool? Basically that, plus I'm friends with Chad so I want to represent. But it's not a huge deal. - A --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en -~--~~~~--~~--~--~---
Re: Getting Heroku errors...any updates/suggestions?
A further report... as of 10:30 am my server is totally unavailable as well. heroku logs returns a blank line. heroku db:pull returns Internal server error Hitting the web site gives the ouchie Japanese guy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en -~--~~~~--~~--~--~---
Re: Getting Heroku errors...any updates/suggestions?
I agree with Jason on all counts. I wasn't even following their twitter feed and it didn't occur to me to look there -- I still think of Twitter as a channel for superficial gossip, not mission-critical support alerts. And considering *Twitter's* notorious issues with downtime, I think it's a dangerous precedent for Heroku not to post to other channels -- like perhaps this Google Group, not to mention their own web site -- when things go South. - A On May 16, 11:23 am, Jason McCay jason.mc...@gmail.com wrote: Heroku looks to be back up...but for our app, we were unreliable since 7PM CST last night (first report of customer issues) and it seemed like we were completely down from at least 7AM CST this morning until around 1:00 PM CST today. So, a couple of observations: 1. That was a long period of being down. 2. The Heroku team really has to do a better job of communicating with people when something like this happens. I attempted to find updates through multiple channels (twitter, blogs, irc, and finally this google group) and Heroku had said nothing. Then, after about five hours of being down, they finally start responding on twitter. I love you Heroku...but I have to be able to trust you, too. :) Jason On May 16, 12:36 pm, Alex Chaffee ale...@gmail.com wrote: A further report... as of 10:30 am my server is totally unavailable as well. heroku logs returns a blank line. heroku db:pull returns Internal server error Hitting the web site gives the ouchie Japanese guy. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Heroku group. To post to this group, send email to heroku@googlegroups.com To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en -~--~~~~--~~--~--~---
