Skip to content
This repository has been archived by the owner on Oct 23, 2024. It is now read-only.

v0.14.0-RC1

Pre-release
Pre-release
Compare
Choose a tag to compare
@gkleiman gkleiman released this 18 Dec 13:50
· 3105 commits to master since this release

Changes from 0.13.0 to 0.14.0

Recommended Mesos version is 0.26.0

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

Overview

Expose additional app definition variables

The following environment variables are now available to the tasks:

  • MARATHON_APP_RESOURCE_CPUS contains the value of the app definition cpus value.
  • MARATHON_APP_RESOURCE_MEM contains the value of the app definition mem value, expressed in megabytes.
  • MARATHON_APP_RESOURCE_DISK value of the app definition disk value, expressed in megabytes.
  • MARATHON_APP_LABELS contains list of labels of the corresponding app definition. For example: label1 label2 label3
  • MARATHON_APP_LABEL_NAME contains value of label "NAME" of the corresponding app definition.

Health Checks: allow port instead of portIndex

Previously, the port to be used for health checks could only be specified by supplying a port index. Now it
can also be specified directly using the new port field.

Improved search in the UI

Previously, the user could search through applications using a field which filtered all applications.
In 0.14.0 we replace the filter with a search which leads to a detailed search result view. There are
various improvements in the search interaction, including the user being returned to their former group
context after the search term has been cleared.

Better health status feedback

The health bars in the application list view are now provided in the application detail view. The tooltips
in the overview have been consolidated to make them easier to understand. The styles of the deployment table
have been updated inline with the applications list view. Additionally, it's possible to filter apps by their
health status in the UI.

IP-per-task UI

Some changes have been made in order to support IP-per-task in the API. The relevant part of the app
definition is exposed in the configuration page, and the ipAddresses field is integrated in the task
detail view.

Direct task log downloads from the UI

The stderr and stdout logs can now be downloaded directly from the task view in the UI. The contents of
each task's sandbox is displayed and files are offered for direct download.

EXPERIMENTAL: IP-per-task support

This can drastically simplify service discovery, since you can use
mesos-dns to rely on DNS for service discovery. This enables your
applications to use address-only (A) DNS records in combination with known ports to connect to other
services -- as you would do it in a traditional static cluster environment.

You can request an IP-per-task with default settings like this:

{
  "id": "/i-have-my-own-ip",
  // ... more settings ...
  "ipAddress": {}
}

Marathon passes down the request for the IP to Mesos. You have to make sure that you installed & configured
the appropriate
Network Isolation Modules &
IP Access Manager (IPAM) modules in Mesos. The Marathon support for this feature requires Mesos v0.26.

If an application requires IP-per-task, then it can not request ports to be allocated in the slave.

Currently, this feature does not work in combination with Docker containers. We might still change some
aspects of the API and we appreciate your feedback.

EXPERIMENTAL: Network security groups

If your IP Access Manager (IPAM) supports it, you can refine your IP configuration using network security
groups and labels:

{
  "id": "/i-have-my-own-ip",
  // ... more settings ...
  "ipAddress": {
    "groups": ["production"],
    "labels": {
      "some-meaningful-config": "potentially interpreted by the IPAM"
    }
  }
}

Network security groups only allow network traffic between tasks that have at least one of their configured
groups in common. This makes it easy to disallow your staging environment to interfere with production
traffic.

EXPERIMENTAL: Service Discovery

If an application requires IP-per-task, then it can not request ports to be allocated in the slave. It is
however still possible to describe the ports that the Application's tasks expose:

{
  "id": "/i-have-my-own-ip",
  // ... more settings ...
  "ipAddress": {
    "discovery": {
      "ports": [
        { "number": 80, "name": "http", "protocol": "tcp" }
      ]
    }
      // ... more settings ...
  }
}

Marathon will pass down this information to Mesos (inside the DiscoveryInfo message) when starting new tasks,
mesos-dns will then expose this information through IN SRV records.

In the future Marathon will also fill in the DiscoveryInfo message for applications that don't require
IP-per-task.

Fixed issues

  • #2505 - Provide memory and cpu as environment variables in docker containers
  • #2509 - Leadership not abdicated on ZK connection loss
  • #2558 - If driver finishes with error, Marathon does not abdicate
  • #2620 - Remove dubious functionality to remove orphaned tasks from TaskTracker storage
  • #2647 - Application cmd override causes application to restart repeatedly
  • #2720 - Disabled button has wrong colour
  • #2734 - Invalid validation for multiple ports
  • #2818 - Remove Set[MarathonTask] from TaskTracker
  • #2755 - Memory leak in Marathon UI
  • #2812 - Cannot change configuration of Marathon app after deployment

List of Contributors

Commits Contributor
47 Matthias Veit
30 Peter Kolloch
20 Gastón Kleiman
15 Matthias Eichstedt
4 Pierluigi Cau
2 philipnrmn
2 Hannes Eichblatt
2 Imran Hayder
2 Philip Norman
2 Sunil Shah
1 Johannes 'fish' Ziemke
1 Marcus Wasner
1 Mateusz Gajewski
1 Evan Krall
1 Anton Lindström
1 Nikita Melkozerov
1 Orlando Hohmeier
1 Andy Grunwald
1 Yo Sub Kwon
1 Alexander Weber
1 Rajashree Mandaogane
1 ReadmeCritic
1 Albert van 't Hart
1 Tomasz Janiszewski
1 James Earl Douglas

Generated by git shortlog -s -n v0.13.0..v0.14.0-RC1 for the Marathon repository