Skip to content

v1.7.174
Compare
Choose a tag to compare
@kensipe kensipe released this 28 Nov 22:08
· 400 commits to master since this release
v1.7.174
da9365d

Changes to 1.7.174

Marathon framework ID generation is now very conservative

Previously, Marathon would automatically request a new framework ID from Mesos if the old one was marked as torn down in Mesos, or if the framework ID record was removed from Zookeeper. This has led to more trouble than it has helped. The new behavior is:

  • If Marathon's framework ID has been torn down in Mesos, or if the failover timeout has been exceeded, Marathon will crash, on launch, with a clear message.

  • If Marathon's framework ID record was deleted from Zookeeper or is otherwise inaccessible, and there are instances defined, Marathon will refuse to create a new Framework ID and crash.

For more information, refer to the framework id docs page.

Minimum Mesos version requirement has been increased to 1.5.0

In previous Marathon versions, we monitored offers as a surrogate terminal task status signal for resident tasks in order to work around a Mesos issue in which we would not receive terminal task status updates for agents that restarted. As of Mesos 1.4.0, this is been resolved, and we have removed this workaround.

There are still some edge cases where Mesos agent metadata is wiped (manually, by an operator) in a way that the agent ID will change, but reservations will be preserved. In these cases, Mesos will report a resident tasks as perpetually unreachable. Operators should use the MARK_AGENT_GONE call in such cases to get Mesos to mark the associated resident tasks as terminal, and therefore signal to Marathon that it should try to relaunch the resident task. This call was introduced in Mesos 1.5.0.

Native Packages

We have stopped publishing native packages for operating system versions that are past their end-of-life:

  • Ubuntu Yakkety
  • Ubuntu Wily
  • Ubuntu Vivid

Additionally, we have added support for Debian Stretch.

Docker image now allows user nobody; default user has been changed

Previously, the Marathon Docker container would only run as user root. The packaging has been updated so that the container is now run, by default, as the user nobody.

NOTE This is a breaking change! If you did not specify MARATHON_MESOS_USER before, and did not specify the container user of nobody when launching Marathon in a container before, then add the environment value MARATHON_MESOS_USER=root to the containerized Marathon.

Non-leader/standby Marathon instances respond to /v2/events with a redirect, rather than proxy

Previously, Marathon standby instances would proxy the event stream. This causes an unnecessary increase in event stream drops, as the connection will terminate if either the master or the standby restarts. Further, there have been occasional buffering issues.

Now, when a standby Marathon instance is asked for /v2/events, it responds with a 302, with a redirect response directing the client to /v2/events resource for the current leader. Clients that consume the event stream should be updated to follow redirect responses.

Event-proxying has the following deprecation schedule:

  • 1.7.x - Standby Marathon instances return redirect responses. The old behavior of proxying event streams can be brought back with the command-line argument --deprecated_features=proxy_events.
  • 1.8.x - Event stream proxying logic will be completely removed. If --deprecated_features=proxy_events is still specified, Marathon will refuse to launch, with an error.

Default for "max-open-connections" increased for asynchronous standby proxy, now configurable

In some clusters with heavy standby-proxy usage, a limit of 32 max-open-connections was too small. This default has been increased to 64. In addition, the flag --leader_proxy_max_open_connections has been introduced to tune the value further, if needed.

Maintenance Mode Support Production Ready, Now Default

Marathon now declines offers for agents with scheduled maintenance.

Previously, this behavior was enabled by --enable_features maintenance_mode. Operators should remove maintenance_mode from the --enable_features value list, as it now has no effect. In Marathon 1.8.x, including the term maintenance_mode in the --enable_features list will be considered an error.

The flag --disable_maintenance_mode has been introduced. To revert back to the default maintenance mode behavior in Marathon 1.6.x and earlier (ignore), operators can specify --disable_maintenance_mode.

Fixed Issues

  • MARATHON-8409 - You can now launch marathon in Docker as non-root user.
  • MARATHON-8017 - Fixed various issues when posting groups with relative ids.
  • MARATHON-7568 - We now redact any Zookeeper credentials from the /v2/info response endpoint.
  • MARATHON-8326 - Pods can be deleted together with persistent volumes, using a new wipe=true query parameter.
  • Updated version of Marathon UI to 1.3.1:
    • MARATHON-8255 - Marathon UI properly shows fetch URLs in the edit dialog, now.

New Exit Codes

Marathon will indicate with an exit code why it stopped itself. See the docs page for a list of all codes and their meanings.

Assets 2