After installing the new rubber gem, you must rerun the vulcanize command for all the recipes you originally installed. For example, if you orignally used rubber via “rails g vulcanize complete_passenger_postgresql”, run that command again && allow it to overwrite all the conflicts.

Then, using gitx (or your favorite diffing tool), examine all of the differences carefully. Typically you will want to accept any files you haven’t customized, but in general you should accept the files:

• ‘deploy-xxxx’, like “deploy-passenger.rb”. That’s an updated recipe, you need it.
• anything under role => again, that’s part of the new recipe, you need it

However, it gets trickier in the .yml files, because you need to watch out for new options that have appeared, initializing them with appropriate defaults, while making sure that you preserve your application-specific values.

deploy.rb is another file to carefully hand merge any custom steps you might have with the new code.

You should also double check that there aren’t files that need to be manually deleted since vulcanize doesn’t track if a file has been removed from a recipe.

Rubber switched to using RVM for ruby management in rubber 1.5.0. If you don’t change your rubber configuration, things will likely still work for you, but it’s not recommended and results may vary. NB: This will not affect running instances; it is only important for newly created instances.

In order to set up RVM for your project you must revulcanize the base module via either:

./script/generate vulcanize base

Or

vulcanize base

Once you revulcanize, you can configure the Ruby you use by modifying the config/rubber/rubber-rvm.yml file. If you were previously using Ruby Enterprise Edition (REE), note that the use_enterprise_ruby setting is no longer honored and you should configure REE in the rubber-rvm.yml file.

Rubber switched to using fog as the basis for all cloud operations. This means fewer dependencies for the project as fog is rather comprehensive and almost wholly contained. If you’re already using fog for your project, you’ll need to make sure the version you’re using matches what rubber requires.

Rubber < 2.0.0 provides rake tasks and a handful of scripts to perform a variety of utility operations. Between RVM, bundler, broken RubyGems upgrades, and broken rake updates, ensuring these tasks worked was a constant hassle. With rubber 2.0.0, the tasks have been replaced by a rubber command that is wholly contained to avoid any sort of dependency chain issues. For example, now you would run rubber cron instead of using the old cron-runner script.

To learn more about how to use the new command, run rubber --help.

Munin is a great monitoring and graphing package. Unfortunately, it requires a lot of resources to run well and that was creating issues for users with even modestly-sized clusters. We’ve replaced munin with the collectd & graphite combination. This is much lighter weight and makes it considerably easier to create graphs with arbitrary metrics on the fly. One down side with the migration is we lost the default set of munin graphs, so you’ll have to manually construct that in your dashboard. We’re looking to add default recipes into rubber for future releases.

Capistrano has a task for precompiling assets when using the asset pipeline. This task, however, ties into the deploy lifecycle earlier than will work when using rubber, since not all the config has been generated yet. Rubber 2.0.0 fixes this problem, so precompiling assets will work out of the box. We’ve also updated the web server configuration to optimize for the asset pipeline if enabled.

Rubber < 2.0.0 supports both old style Rails 2.x gem management and bundler dependency management. In rubber 2.0.0 we’ve dropped the special handling of Rails 2.x gem management. If you want gems installed as part of your deploy, you’ll need to use bundler or write your own tasks. Note that Rails 2.x itself will still work fine for a deploy, it’s just treated as any other non-Rails app you would configure with rubber.

• Re-vulcanize all the modules you previously had installed. This will give you a pretty good base to work with. You will undoubtedly have to manually merge some config.
• Remove old rubber scripts since these are no longer used (script/cron-rake, script/cron-runner, script/cron-sh).
• Remove the rubber rake tasks file (lib/tasks/rubber.rake)
• Port any custom munin plugins over to collectd. Rubber provides some utilities to make this easier. See script/collectd/role/examples/* for some examples.