tsr 0.11.0 release notes¶
Welcome to tsr 0.11.0!
These release notes cover the new features, bug fixes, general 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. #1110
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. #1137Added 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. #1138It’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. #986Graceful 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.
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. #1110Queue 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.