On behalf of the Marathon contributors, we are pleased to announce the availability of Marathon version 0.8.0. Alongside a number of small feature additions, this release focuses on improving the overall performance and stability of Marathon. Below is an overview of the most important feature additions. For a complete overview see the release notes on GitHub.
Deployments can now be stopped
Prior to the 0.7.x series when an app was launched with Marathon, the scheduler would just try to scale it to the expected number of instances. In 0.7.0 we introduced deployments whereby Marathon would monitor the process and visualize the progress of a deployment in the UI. If a deployment didn’t finish – e.g. because the apps didn’t become healthy or there was not enough capacity in the cluster – there is the ability in versions of Marathon 0.7.x and later to rollback to an older version of the deployment that is known to work. However, sometimes you might just want to cancel a deployment rather than initiate a rollback, so in 0.8.0 we added the ability to cancel a deployment. Be mindful when you cancel a deployment, as the apps affected by the cancelation will stay in the faulty state.
Apps can now have labels
Attaching metadata to apps can be useful to expose additional information to other services, so we added the ability to place labels on apps (for example, you could label apps “staging” and “production” to mark services by their position in the pipeline). The soon to be released Mesos 0.22.0 will also add labels to tasks and the Marathon team will add support for task labels as well with a minor update.
UI now shows the latest state in case of connection loss
Prior to 0.8.0 the web UI would show an error message when it could not fetch the status of an app, but you could not see the app’s last known state. In Marathon 0.8.0, we’ve extended the UI so that it also shows the last known state.
maximumOverCapacity in upgradeStrategy
When you deploy an app, you usually want to keep a certain number of instances alive to process the incoming requests and for that we have the
minimumHealthCapacity. In addition to
minimumHealthCapacity which makes sure that a given number of instances will always be healthy during a deployment, we’ve added a new setting,
maximumOverCapacity, which allows Marathon to exceed the app’s number of
instances quota during deployment by the specified factor. Provided you have extra capacity in your cluster
maximumOverCapacity can make for faster and more robust deployments because it gives Marathon the ability to ensure all the new instances become healthy before killing the old ones
New endpoint /v2/leader
A new endpoint has been added that allows users to retrieve the current leader by sending a
GET, or force the current leader to abdicate its leadership and start a new election by sending a
Docker parameters can have multiple values
The representation of Docker parameters in the app JSON has changed to allow for multiple values for a given parameter name.
Optimized task queueing
With the new optimized task queuing behaviour in Marathon it is possible to enqueue huge numbers of tasks without performance degradation.
New option maxLaunchDelay
In addition to the
backOffFactor it is now possible to configure the
maximumLaunchDelay which before had been hard coded to 1 hour.