tsr 0.11.0 release notes

Welcome to tsr 0.11.0!

These release notes cover the new features, bug fixes, other improvements and backward incompatible changes you’ll want to be aware of when upgrading from tsr 0.10.0 or older versions.

Main new features

• Pool management overhaul. Now pools are a concept independent on the docker provisioner. You can have multiple pools associated with each team. If that’s the case, when creating a new application, users will be able to choose which pool they want to use to deploy it.

  To support these features some client commands have changed, mainly tsuru app-create support a --pool <poolname> parameter.

  Some action is needed to migrate old pool configuration to this new format. See backward incompatible changes section for more details. #1013

• Node auto scaling. It’s now possible to enable automatic scaling of docker nodes, this will add or remove nodes according to rules specified in your tsuru.conf file. See node auto scaling topic and config reference for more details. #1110

Bug fixes

• Better handling erroneous tsuru.yaml files with tabs instead of spaces. #1165
• Restart after hooks now correctly run with environment variables associated to applications. #1159
• tsuru app-shell command now works with tsuru api under TLS. #1148
• Removing machines from IaaS succeed if referenced machine was already manually removed from IaaS. #1103
• Deploy details API call (/deploy/<id>) no longer fail with deploys originated by running tsuru app-deploy. #1098
• Cleaner syslog output without lots of apparmor entries. #997
• Running tsuru app-deploy on Windows now correctly handle directories and home path. #1168 #1169
• Application listing could temporarily fail after removing an application, this was fixed. #1176
• Running tsuru app-shell now correctly sets terminal size and TERM environment value, also container id is no longer ignored. #1112 #1114
• Fix bug in the flow of binding and unbinding applications to service instances. With this old bug, units could end-up being bound twice with a service instance.

Other improvements

• Limited number of goroutines started when initiating new units, avoiding starving docker with too many simultaneous connections. #1149

• There is now a tsr command to run necessary migrations when updating from older versions. You can run it with tsr migrate and it should not have side- effects on already up-to-date installations. #1137

• Added command tsr gandalf-sync, it should be called if Gandalf is activated on an existing tsuru api instance. It’s responsible for copying existing users and teams credentials to Gandalf. Users added after Gandalf activation in tsuru.conf will already be created on Gandalf and this command doesn’t needed to be called further. #1138

• It’s now possible to remove all units from an application (thanks Lucas Weiblen). #1111.

• Removing units now uses the scheduler to correctly maintain units balanced across nodes when removing a number of units. #1109

• tsuru will keep trying to send image to registry during deploy for some time if the registry fails on the first request. #1099

• It’s possible to use a docker registry with authentication support. See config reference for more details. #1182

• Partial support for docker distribution (registry 2.0). Image removal is not yet supported. #1175

• Improved logging support, allowing cloud admins to configure any of the three tsuru logging options: syslog, stderr or log file. At any time, it’s possible to enable any of the three options.

• Running commands with tsuru app-run now log command’s output to tsuru logs. #986

• Graceful shutdown of API when SIGTERM or SIGINT is received. The shutdown process now is:

  • Stop listening for new connections;
  • Wait for all ongoing connections to end;
  • Forcibly close tsuru app-log -f connections;
  • Wait for ongoing healing processes to end;
  • Wait for queue tasks to finish running;
  • Wait for ongoing auto scaling processes to end.

  #776

• Included lock information in API call returning application information. #1171

• Unit names now are prefixed with application’s name (thanks Lucas Weiblen). #1160.

• Admin users can now specify which user they want removed. #1014

• It’s now possible to change metadata associated with a node. #1016

• Users can now define a private environment variable with tsuru env-set (thanks Diogo Munaro).

• Better error messages on server startup when MongoDB isn’t available (thanks Lucas Weiblen). #1125.

• Add timing information to the healthcheck endpoint, so tsuru admins can detect components that are slow, besides detecting which are down.

• Now tsuru app-remove does not guess app name (thanks Lucas Weiblen). #1106.

• General improvements in the documentation:

  • typo fixes and wording improvements to install and configuration pages (thanks Anna Shipman).
  • fix instructions for key management in the quickstart page (thanks Felippe Raposo).
  • improve documentation for the contributing page (thanks Lucas Weiblen).
  • fix user creation instruction in the installing page (thanks Samuel Roze).
  • fix wording and spelling in the Gandalf install page (thanks Martin Jackson).

Backward incompatible changes (action needed)

• There are two migrations that must run before deploying applications with tsr 0.11.0, they concern pools and can be run with tsr migrate. The way pools are handled has changed. Now it’s possible for a team to have access to more than one pool, if that’s the case the pool name will have to be specified during application creation. #1110

• Queue configuration is necessary for creating and removing machines using a IaaS provider. This can be simply done by indicating a MongoDB database configuration that will be used by tsuru for managing the queue. No external process is necessary. See configuration reference for more details. #1147

• Previously it was possible for more than one machine have the same address this could cause a number of inconsistencies when trying to remove said machine using tsuru docker-node-remove --destroy. To solve this problem tsuru will now raise an error if the IaaS provider return the same address of an already registered machine.

  If you already have multiple machines with the same address registered in tsuru, trying to add new machines will raise an error until the machines with duplicated address are removed.