tsr 0.9.0 release notes¶
Welcome to tsr 0.9.0!
These release notes cover the new features, bug fixes, backward incompatible changes, general improvements and changes in the API you’ll want to be aware of when upgrading from tsr 0.8.0 or older versions.
What’s new in tsr 0.9.0¶
- Now tsuru users can generate an API key, enabling authentication with no
interactions required and having a token that never expires. Users can
generate a new API key at any time using the command
tsuru token-regenerateto replace the old one. To view the current key that you own, just use the command
- It’s possible to use templates to create machines in the IaaS provider with
docker-node-add. See machine-template-add command for more details.
TSURU_SERVICESenvironment variable: this environment variable lists all service instances that the application is bound. This enables binding an application to multiple instances of a service (issue #991). For more details, check the TSURU_SERVICES documentation.
- auto scale: tsuru now includes an experimental support for auto scale. The auto scale uses the
metric system to know when scale.
To enable auto scale you should add the
autoscale: truein then
- app: SetEnvs not return error in apps with no units (issue #954).
- iaas/ec2: fixed panic after machine creation timeout.
Other improvements in tsr 0.9.0¶
- Improvements to EC2 IaaS provider, it now accepts user-data config through
iaas:ec2:user-dataand a timeout for machine creation with
- A new debug route is available in the API:
/debug/goroutines. It can only be hit with admin credentials and will dump a trace of each running goroutine.
Backward incompatible changes¶
- Service API flow: the service API flow has changed, splitting the bind process in two steps: binding/unbinding the application and binding/unbinding the units. The old flow is now deprecated (issue #982).
For more details on the API, please refer to the tsuru API documentation.
/users/keys: in previous versions of the API, this endpoint was used for adding and removing keys from the user account. Now it also lists the keys registered in the account of the user. Here is a summary of the behavior of this endpoint:
GET: return the list of keys registered in the user account
POST: add a new SSH key to the user account
DELETE: remove a SSH key from the user account
For the two last kind of requests, the user is now able to specify the name of the key, as well as the content.