tsr 0.5.0 release notes

Welcome to tsr 0.5.0!

These release notes cover the new features and backwards incompatible changes you’ll want to be aware of when upgrading from tsr 0.4.0 or older versions.

What’s new in tsr 0.5.0

Stability and Consistency

One of the main feature on this release is improve the stability and consitency of the tsuru API.

  • prevent inconsitency caused by problems on deploy (#803) / (#804)
  • units information is not updated by collector (#806)
  • fixed log listener on multiple API hosts (#762)
  • prevent inconsitency caused by simultaneous operations in an application (#789)
  • prevent inconsitency cause by simultaneous env-set calls (#820)
  • store information about errors and identify flawed application deployments (#816)

Buildpack

tsuru now supports deploying applications using Heroku Buildpacks.

Buildpacks are useful if you’re interested in following Heroku’s best practices for building applications or if you are deploying an application that already runs on Heroku.

tsuru uses Buildstep Docker image to deploy applications using buildpacks. For more information, take a look at the buildpacks documentation page.

Other features

  • filter application logs by unit (#375)
  • support for deployments with archives, which enables the use of the pre-receive Git hook, and also deployments without Git (#458, #442 and #701)
  • stop and start commands (#606)
  • oauth support (#752)
  • platform update command (#780)
  • support services with https endpoint (#812) / (#821)
  • grouping nodes by pool in segregate scheduler.

Platforms

  • deployment hooks support for static and PHP applications (#607)
  • new platform: buildpack (used for buildpack support)

Backwards incompatible changes

  • Juju provisioner was removed. This provisioner was not being maintained. A possible idea is to use Juju in the future to provision the tsuru nodes instead of units
  • ELB router was removed. This router was used only by juju.
  • tsr admin was removed.
  • The field units was removed from the collection apps. Information about units are now available in the provisioner. Now the unit state is controlled by provisioner. If you are upgrading tsuru from 0.4.0 or an older version you should run the MongoDB script below, where the docker collection name is the name configured by docker:collection in tsuru.conf:
var migration = function(doc) {
    doc.units.forEach(function(unit){
        db.docker.update({"id": unit.name}, {$set: {"status": unit.state}});
    });
};

db.apps.find().forEach(migration);
  • The scheduler collection has changed to group nodes by pool. If you are using this scheduler you shoul run the MongoDB script below:
function idGenerator(id) {
    return id.replace(/\d+/g, "")
}

var migration = function(doc) {
    var id = idGenerator(doc._id);
    db.temp_scheduler_collection.update(
        {teams: doc.teams},
        {$push: {nodes: doc.address},
         $set: {teams: doc.teams, _id: id}},
        {upsert: true});
}
db.docker_scheduler.find().forEach(migration);
db.temp_scheduler_collection.renameCollection("docker_scheduler", true);

You can implement your own idGenerator to return the name for the new pools. In our case the idGenerator generates an id based on node name. It makes sense because we use the node name to identify a node group.

Features deprecated in 0.5.0

beanstalkd queue backend will be removed in 0.6.0.