v0.13.0-RC6

Fixed Issues

• #2719 - Show correct button label when creating inside group
• #2684 - Running instances are confusing

Changelog

Changelog from Marathon 0.13.0-RC5 to 0.13.0-RC6: v0.13.0-RC5...v0.13.0-RC6

Please see the release notes of v0.13.0-RC1 for a complete list of the changes in v0.13.0.

v0.13.0-RC5

Fixed Issues

• #2681 - Circumvent cache if not yet preloaded
• #2699 - App list health bar update/render issue

Changelog

Changelog from Marathon 0.13.0-RC4 to 0.13.0-RC5: v0.13.0-RC4...v0.13.0-RC5

Please see the release notes of v0.13.0-RC1 for a complete list of the changes in v0.13.0.

v0.13.0-RC4

Fixed Issues

• #2634 - UI does not update/show the status correctly
• #1780 - When app is locked by deployment, deleting tasks via the UI does nothing
• #2626 - Status icons are rendered blotted
• #2627 - Tasks health column shows different health status
• #2615 - Keep input focus position when updating the Filter bar

Changelog

Changelog from Marathon 0.13.0-RC3 to 0.13.0-RC4: v0.13.0-RC3...v0.13.0-RC4

Please see the release notes of v0.13.0-RC1 for a complete list of the changes in v0.13.0.

v0.13.0-RC3

Fixed Issues

• #2599 Cache for EventSubscribers not populated on startup
• #2603 ActorLogging warning does not expand Throwable
• #2593 Very long labels expand horizontal scrollbar in app list

Changelog

Changelog from Marathon 0.13.0-RC2 to 0.13.0-RC3: v0.13.0-RC2...v0.13.0-RC3

Please see the release notes of v0.13.0-RC1 for a complete list of the changes in v0.13.0.

v0.13.0-RC2

Fixed Issues

• Fixes #2314 - Do not remove health checks that are still needed
• Fixes #2322 - count tasks without explicit state as staging
• Fixes #2565 - Change app icon title from "Basic" to "Application"
• Fixes #2568 - UI: App state incorrectly shown
• Fixes #2574 - Label Filter: Filter Label Box is not cleared
• Fixes #2585 - Sorting by CPU causes row column to expand
• Fixes #2586 - Sorting by Status shifts heading text

Changelog

Changelog from Marathon 0.13.0-RC1 to 0.13.0-RC2: v0.13.0-RC1...v0.13.0-RC2

Please see the release notes of v0.13.0-RC1 for a complete list of the changes in v0.13.0.

v0.13.0-RC1

Changes from 0.11.1 to 0.13.0

Breaking Changes

Tasks keys and storage format in ZooKeeper

Marathon tasks are now stored in ZooKeeper using a generic implementation that has been around for
a while. In order to accomplish this, the keys under which tasks are stored had to be migrated and
do no longer contain redundant information about the app id. Additionally, the task storage format
in Zookeeper changed as well. Previous versions of Marathon will not be able to read the tasks'
status once these are migrated. Please backup your ZooKeeper state before migrating to this version.

Zookeeper Compression

ZK nodes larger than a certain threshold will now be compressed. This allows Marathon to handle
more apps and groups, but breaks backwards compatibility, because older versions of Marathon are
not able to parse compressed nodes. You can define the threshold with --zk_compression_threshold
which defaults to 64KB.
To disable this feature, start Marathon with the --disable-zk-compression flag.

Use logback as logging backend

We moved from log4j to Logback backend.
If you are using custom log4j properties, you will have to migrate them to a logback configuration.
The log4j.properties to logback.xml Translator can help you with that.

Overview

Major changes to the UI layout

This version introduces major changes to the layout. In particular, the application list has been redesigned.

• A filter sidebar is introduced with the ability to combine filters or clear them.
  • Filter by application status
  • Filter by labels
• The application list now handles groups
• Groups are shown at the top of the application list
• A group route is introduced to display the contents of a group in the application list
• Breadcrumbs show the groups structure
• Breadcrumbs will be folded to "..." when there isn't room to render them in full
• App names are now shown in the app page and app list instead of app IDs
• The complete app ID is available in the configuration tab
• Application labels are shown by the application name in the application list
• Endpoints are shown in the tasks detail page
• The memory column shows the total amount of memory used by an application with a human readable unit
• The application status is displayed with a colored icon
• The instances and health columns have been combined into one called "Running Instances"
• The control buttons on the application page are shown on the left and are redesigned

Enable extensions to Marathon via Plugins

This version of Marathon ships with the ability to load and use external plugins.
With this functionality in place, you can extend and adapt functionality in Marathon to your specific needs.
We start this adventure with pluggable authentication and authorization hooks, but want to extend this
to various functionality inside of Marathon.

To start with this feature, please read Plugin Documentation or see our Example Plugins.

Please check it out and give us feedback!
We are also interested in any recommendations for upcoming plugin hooks.

Pluggable Authentication and Authorization hooks

The probably most wanted feature in Marathon is the ability to have Authentication and Authorization.
Since this topic has so distinct requirements for different organizations, it is a perfect match for our new plugin mechanism. This version now implements all the necessary hooks needed to secure most external interfaces to your specific needs. If you are interested in a very simple implementation, you can look into the Example Auth Plugin

Persistent Store Cache

All entities in the persistent store (ZK) are loaded into a cache during leader election.
Subsequent reads are delivered from that cache. Updates to entities also update the cache.
This cache should improve read access time significantly.
You can disable the cache with --disable_store_cache.

Greatly improved API Reference

With this release we integrated RAML based API documentation.
The /help endpoint uses the RAML Console to show the API Reference.
The Github pages documentation now also uses that specification.
We had a lot of feedback for documentation improvements - so please give us your thoughts on that.

Graphite and DataDog reporter

We collect a lot of metrics in Marathon.
You can collect those metrics via the /metrics endpoint.
With those reporters you can transfer the data into either Graphite or DataDog and see the values over time.

Force action

Previous versions of the UI did not support sending the ?force=true query parameter when the
user submitted a scale action or when changing an app's configuration. These actions would be
rejected if the app was locked by one or more deployments.
In this version, the user is presented with a modal confirmation dialog when a force action is
required to proceed.

Authentication errors

Authentication errors (401, 403) are now notified to the user by means of modal dialogs.

Improved application modal

The application create/edit modal has undergone significant architectural and UX improvements.
It is now possible to specify application labels, accepted resource roles, the user field and
health checks. Additionally, a more fine-grained input validation and error handling has been
implemented.

Bookmarkable search results

The text entered in the filter bar is immediately stored in the browser's URL bar, which makes
search results bookmarkable for quicker access.

Application detail view: configuration panel

The Configuration panel in the application's detail view sees a number of improvements and bug
fixes. The application labels and dependencies are now also shown, and the lifetime durations
are shown as "humanized".

Define the number of maximum apps

A new flag (--max_apps) has been introduced, which allows Marathon to limit the maximum number
of applications that may be created. This limit is disabled by default.

Under the Hood

Introduce a plugin-interface module

We now publish a separate marathon-plugin-interface.jar with every Marathon release on our maven repository.
This artifact holds all the inerfaces needed to develop your own Marathon plugin.

Consolidate logging to use slf4j

We moved completely to slf4j as Logging API.

Several performance improvements

• A separate thread pool is used for health check operations
• Group and app creation is more efficient.

Introduce configurable zk node compression

We introduced zk compression which improves performance significantly. Compression can be turned on/off via cmd line flags and is enabled by default.

Tasks are now stored via the standard EntityRepository

The storage of tasks was handled separately in previous versions of Marathon.
With this change in place we handle all entities via the same interface.
This allows for globally available extensions (e.g. the store cache).

Fixed Issues

• #1429 - Non-integer is accepted as instance count
• #1563 - Inconsistent /help <-> rest-api.md documentation
• #1588 - Incorrect healthcheck triggers 500 Server error
• #1730 - Add uptime metric
• #1835 - No error received when a DELETE is sent to a task in deployment
• #1904 - App scaled below minimumHealthCapacity
• #1985 - Docker container settings dialog needs better error handling
• #1988 - Move from log4j to logback
• #2157 - Row is off-centre if upper row is empty in lists
• #2174 - REST api returns code 500 for invalid JSON and fails silently to proxy the error
• #2177 - Error Handling/validation required for COMMAND health check
• #2202 - App not present right after its creation
• #2216 - Do not show (x) in keyword search input until user begins typing
• #2256 - Misleading log message if offer doesn't match because of filtered roles
• #2262 - Better error handling on application configuration change/creation
• #2264 - Cannot submit job with id containing internal slashes
• #2266 - Link "Mesos details" is broken
• #2270 - Overlapping text in Deployment view
• #2280 - Scaling check ignores task versions
• #2294 - Make boolean command line flags use Scallop's 'toggle'
• #2299 - Writes to EntityRepositories should be visible in following reads
• #2307 - Investigate MarathonSchedulerServiceTest failure
• #2338 - Parameters in the Docker container settings are not taken into account
• #2353 - Never recover from race condition when scaling up
• #2360 - PUT /v2/groups triggers restart while PUT /v2/apps does not
• #2369 - Large file URIs cause "Failed to fetch all URIs for container" error when pulling from HDFS
• #2381 - Marathon stops apps instead of restart
• #2398 - Blank docker image is created in app modal
• #2402 - Runtime privilege checkbox does not work
• #2405 - Migration of ZK State to 0.13 does not work
• #2421 - Invalid calling object (Win 8 IE10, Win 7 IE11)
• #2422 - Handle apps error response attribute on HTTP 422
• #2441 - AppRestart deployments don't wait for old tasks to be killed
• #2494 - Remove mentions of Marathon gem from docs
• #2459 - Framework Id not visible in the UI
• #2477 - Marathon forgets all tasks on restart

List of Contributors

Commits	Contributor
74	Matthias Veit
57	Gastón Kleiman
25	Peter Kolloch
17	sascala
13	Matthias Eichstedt
5	Marcus Wasner
5	Connor Doyle
4	Philip Norman
3	Tamar Ben-Shachar
3	Gastón Kleiman
2	Tomasz Janiszewski
2	Felix Gertz
2	mattpennathe3rd
2	Sebastien Le Digabel
1	alon-argus
1	pbnsilva
1	Lukas Lösche
1	Harpreet Singh Gulati
1	José Moreira
1	Matthias Lüneberg
1 ...

v0.11.1

Changes from 0.11.0 to 0.11.1

Overview

This release includes fixes for critical bugs introduced in v0.11.0 and several performance
improvements that allow Marathon to handle a larger number of groups and applications.

Performance Improvements

This release introduces the following improvements which allow Marathon to handle a larger number of
applications. Because this is a bugfix release and they are not backwards compatible, they are are
available, but disabled by default:

• ZK nodes larger than a certain threshold can now be compressed. This allows Marathon to handle
  more apps and groups, but breaks backwards compatibility, because older versions of Marathon are
  not able to parse compressed nodes.

  To enable this feature, start Marathon with the --zk_compression flag.

• A new flag (--max_apps) has been introduced, which allows Marathon to limit the maximum number
  of applications that may be created. This limit is disabled by default, but we performed scale
  tests on this release and recommend setting the limit to 500.

Fixed issues

• #2353 - Never recover from race condition when scaling up
• #2369 - Large file URIs cause "Failed to fetch all URIs for container" error when pulling from HDFS
• #2360 - PUT /v2/groups triggers restart while PUT /v2/apps does not
• #2381 - Marathon stops apps instead of restart

Downloads

Tarball:
http://downloads.mesosphere.io/marathon/v0.11.1/marathon-0.11.1.tgz

SHA:
http://downloads.mesosphere.io/marathon/v0.11.1/marathon-0.11.1.tgz.sha256

Docker:
https://registry.hub.docker.com/u/mesosphere/marathon with tag v0.11.1

Packages are also available via the Mesosphere repositories.
See: https://mesosphere.com/blog/2014/07/17/mesosphere-package-repositories/

v0.12.0-RC1

Changes from 0.11.0 to 0.12.0

Recommended Mesos version is 0.24.0

We tested this release against Mesos version 0.24.0. Thus, this is the recommended Mesos version for this release.

Overview

Enable extensions to Marathon via Plugins

This version of Marathon ships with the ability to load and use external plugins. With this functionality in place, you can extend and adapt functionality in Marathon to your specific needs. We start this adventure with pluggable authentication and authorization hooks, but want extend this to various functionality inside of Marathon.

To start with this feature, please read Plugin Documentation or see our Example Plugins.

Please check it out and give us feedback! We are also interested in any recommendations for upcoming plugin hooks.

Pluggable Authentication and Authorization hooks

The probably most wanted feature in Marathon is the ability to have Authentication and Authorization. Since this topic has so distinct requirements for different organizations, it is a perfect match for our new plugin mechanism.
This version now implements all the necessary hooks needed to secure most external interfaces to your specific needs. If you are interested in a very simple implementation, you can look into the Example Auth Plugin

Force action

Previous versions of the UI did not support sending the ?force=true query parameter when the
user submitted a scale action or when changing an app's configuration. These actions would be
rejected if the app was locked by one or more deployments.
In this version, the user is presented with a modal confirmation dialog when a force action is
required to proceed.

Authentication errors

Authentication errors (401, 403) are now notified to the user by means of modal dialogs.

Improved application modal

The application create/edit modal has undergone significant architectural and UX improvements.
It is now possible to specify application labels, accepted resource roles, the user field and
health checks. Additionally, a more fine-grained input validation and error handling has been
implemented.

Bookmarkable search results

The text entered in the filter bar is immediately stored in the browser's URL bar, which makes
search results bookmarkable for quicker access.

Application detail view: configuration panel

The Configuration panel in the application's detail view sees a number of improvements and bug
fixes. The application labels and dependencies are now also shown, and the lifetime durations
are shown as "humanized".

Under the Hood

Introduce a plugin-interface module

We now publish a separate marathon-plugin-interface.jar with every Marathon release on our maven repository. This artifact holds all the inerfaces needed to develop your own Marathon plugin.

Consolidate logging to use slf4j

We moved completely to slf4j as Logging API. The logging backend still uses log4j.

Fixed Issues

• #2294 - Make boolean command line flags use Scallop's 'toggle'

v0.11.0

Changes from 0.10.0 to 0.11.0

Attention! There have been some severe issues reported for 0.11. We will release fixes for them in 0.11.1.

Breaking Changes

• Java 8 or higher is needed to run Marathon, since Java 6 and 7 support has reached end of life.
• --revive_offers_for_new_apps is now the default. If you want to avoid resetting filters if new tasks need to be started, you can disable this by --disable_revive_offers_for_new_apps.
• Dynamic ports are no longer pseudo-deterministically assigned.

Overview

We tested this release against Mesos version 0.23. Thus, this is the recommended Mesos version for this release.

Marathon uses Java 8

Java 8 has been out for more than a year now. The support for older versions of Java has reached end of life. We switched completely to the latest stable JVM release. We compile, test and run Marathon against Java 8.

Note for the Marathon Docker image: the base image of Marathon is now the standard java:8-jdk docker image.

Faster reconciliation and links to task Mesos sandboxes

Marathon now saves the slaveID of newly launched tasks. That leads to faster reconciliation for lost tasks and allows the UI to link to the mesos UI.

If the auto-discovered mesos UI is not reachable from wherever you access the Marathon UI from, you can use the --mesos_leader_ui_url configuration to change the base URL of these links.

New versioning information in API and UI

We now have versionInfo with lastConfigChangeAt and lastScalingAt in the apps JSON of our API. lastConfigChangeAt is the timestamp of the last change to the application that was not just a restart or a scaling operation. lastScalingAt is the time stamp of the last scaling or restart operation.

Additional task statistics in the /v2/apps and /v2/apps/{app id} endpoints (Optional)

If you pass embed=apps.taskStats/embed=app.taskStats as a query parameter, you get additional taskStats embedded in you app JSON.

Task statistics are provided for the following groups of tasks. If no tasks for the group exist, no statistics are offered:

• withLatestConfig contains statistics about all tasks that run with the same config as the latest app version.
• startedAfterLastScaling contains statistics about all tasks that were started after the last scaling or restart operation.
• withOutdatedConfig contains statistics about all tasks that were started before the last config change which was not simply a restart or scaling operation.
• totalSummary contains statistics about all tasks.

Example JSON:

{
  // ...
  "taskStats": {
    {
      "startedAfterLastScaling" : {
        "stats" : {
          "counts" : { // equivalent to tasksStaged, tasksRunning, tasksHealthy, tasksUnhealthy
            "staged" : 1,
            "running" : 100,
            "healthy" : 90,
            "unhealthy" : 4
          },
          // "lifeTime" is only included if there are running tasks.
          "lifeTime" : {
            // Measured from `"startedAt"` (timestamp of the Mesos TASK_RUNNING status update) of each running task
            // until now.
            "averageSeconds" : 20.0,
            "medianSeconds" : 10.0
          }
        }
      },
      "withLatestConfig" : {
        "stats" : { /* ... same structure as above ... */ }
      },
      "withOutdatedConfig" : {
        "stats" : { /* ... same structure as above ... */ }
      },
      "totalSummary" : {
        "stats" : { /* ... same structure as above ... */ }
      }
    }
  }
  // ...
}

The calculation of these statistics is currently performed for every request and expensive if you have very many tasks.

Specific "embed" parameters for app related information

In this release, we introduce "embed" parameters for all GET requests in the app end-point that specify which information to embed. Right now, we deliver all information by default that we delivered before but we encourage you to specify embed parameters for the information that you need.

In the future, we will only deliver information you explicitly requested by default, even though we will allow some compatibility configuration option. This improves performance by not returning information that you might not need.

Smarter resource offer handling

When Marathon needed to launch tasks for multiple apps, it would first launch all needed tasks for the first one and then proceed to the next app. One big deployment could block all others. In this new version, Marathon will spread the offers among all apps that currently need to launch tasks.

When Marathon detects new tasks that it has to launch, it will now explicitly request new offers with the reviveOffers Mesos scheduler API call. This should result in more speedy task launches. If for any reason you dislike this behavior, you can disable it with --disable_revive_offers_for_new_apps (not recommended).

The order in which mesos receives reviveOffers and declineOffer calls is not guaranteed. Therefore, as long as we still need offers to launch tasks, we repeat the reviveOffers call for --revive_offers_repetitions times so that our last reviveOffers will be received after all relevant declineOffer calls with high probability.

• --revive_offers_repetitions (Optional. Default: 3): Repeat every reviveOffer request this many times, delayed by the --min_revive_offers_interval.

When Marathon has no current use for an offer, it will decline the offer for a configurable period. A short duration might lead to resource starvation for other frameworks if you run many frameworks in your cluster. You should only need to reduce it if you use --disable_revive_offers_for_new_apps.

• --decline_offer_duration (Default: 120 seconds) The duration (milliseconds) for which to decline offers by default

New task launching tuning parameters

To prevent overloading Mesos itself, you can now restrict how many tasks Marathon launches per time interval. By default, we allow 1000 unconfirmed task launches every 30 seconds. In addition, Marathon considers TASK_RUNNING status updates from Mesos as launch confirmations and allows launching one more task for every confirmed launch.

• --launch_token_refresh_interval (Optional. Default: 30000): The interval (ms) in which to refresh the launch tokens to --launch_token_count.
• --launch_tokens (Optional. Default: 1000): Launch tokens per interval.

As a result of this, the --max_tasks_per_offer_cycle options is deprecated and has no effect anymore.

To prevent overloading Marathon and maintain speedy offer processing, there is also a timeout for matching each incoming resource offer, i.e. finding suitable tasks to launch for incoming offers.

• --offer_matching_timeout (Optional. Default: 1000): Offer matching timeout (ms). Stop trying to match additional tasks for this offer after this time. All already matched tasks are launched.

All launched tasks are stored before launching them. There is also a new timeout for this:

• --save_tasks_to_launch_timeout (Optional. Default: 3000): Timeout (ms) after matching an offer for saving all matched tasks that we are about to launch. When reaching the timeout, only the tasks that we could save within the timeout are also launched. All other task launches are temporarily rejected and retried later.

If the mesos master fails over or in other unusual circumstances, a launch task request might get lost. You can configure how long Marathon waits for the first TASK_STAGING update.

• --task_launch_confirm_timeout (Optional. Default: 10000): Time, in milliseconds, to wait for a task to enter the TASK_STAGING state before killing it.

No pseudo-deterministic assignment of host ports anymore

If you specify non-zero "ports" in your app JSON, they are used as service ports. The old code contained logic that would assign these ports as host ports if available in the processed offer. That misled people into thinking that these ports corresponded to host ports. The new code always randomizes host ports assignment without "requirePorts" or explicit "hostPort" configuration.

Last task failures are persisted

Marathon has exposed the "lastTaskFailure" via the API for a while but this information was not persisted across restarts or on fail over. Now it is.

Logging command line parameters on startup

Marathon will now log all command line parameters on startup. Example:

2015-08-02 11:48:08,047] INFO Starting Marathon 0.11.0-SNAPSHOT with --zk zk://master.mesos:2181/marathon --master master.mesos:5050

Improved logging of deployment plans

Example:

DeploymentPlan 2015-09-02T07:56:12.105Z
step 1:
  * Start(App(app1, cmd="cmd")), instances=0)
step 2:
  * Scale(App(app1, cmd="cmd")), instances=2)

Improved logging of offer rejections

Example for missing port:

[2015-08-04 20:11:20,510] INFO Offer [20150804-173037-16777343-5050-4340-O110]. Cannot find range with host port 8080 for app [/product/frontend]
[2015-08-04 20:11:29,422] INFO Offer [20150804-173037-16777343-5050-4340-O110]. Insufficient resources for [/product/frontend] (need cpus=1.0, mem=64.0, disk=1.0, ports=([8080] required + 1 dynamic), available in offer:
...

Example for missing basic resources:

[2015-08-04 20:17:27,986] INFO Offer [20150804-173037-16777343-5050-4340-O110]. Not all basic resources satisfied: cpu NOT SATISFIED (30.0 > 8.0), disk SATISFIED (0.0 <= 0.0), mem SATISFIED (16.0 <= 15360.0)
[2015-08-04 20:17:27,989] INFO Offer [20150804-173037-16777343-5050-4340-O110]. Insufficient for [/test] (need cpus=30.0, mem=16.0, disk=0.0, ports=(1 dynamic), available in offer:
...

Immediately store changed apps

In the past, Marathon would update the data for the group endpoint when it accepted a new deployment request like a change an app configuration. Marathon would only update the data in t...

v0.11.0-RC5

Fixed Issues

• #2252 - Wrong task number in Debug Tab
• #2317 - Redirect of / should be relative (ui/ not /ui/)
• Respect JAVA_HOME usage within marathon framework

Changelog

Changelog from Marathon 0.11.0-RC4 to 0.11.0-RC5: v0.11.0-RC4...v0.11.0-RC5

Please see the release notes of v0.11.0-RC3 for a complete list of the changes in v0.11.0.