Skip to content

Releases: mesosphere/marathon

v1.3.13

06 Sep 13:36
Compare
Choose a tag to compare

Fixed issues

  • MARATHON-4802 - Constraint migration was not really implemented. This commit makes sure that it is fully implemented. During migration some constraints get sanitized. For instance, ["field", "UNIQUE", "value"] gets transformed to ["field", "UNIQUE"] because the UNIQUE constraint should not have any value. In addition to that the validation of CLUSTER is relaxed, because it doesn't require a value, and such a constraint did not pass the validation before.
  • PR #5487 - Handle socket timeout exception when forwarding requests to a leader.

v1.4.7

23 Aug 09:28
Compare
Choose a tag to compare

Fixed issues

  • MARATHON-7715 - Marathon would not notice an unreachable / lost resident task was gone, or that a reservation should be released, unless if it was idle. This is has been resolved.
  • MARATHON-1703 - Resident task instance placement now properly respects constraints which rely on the placement state of instance peers (such as hostname:UNIQUE).
  • MARATHON-7707 - Resident task instance agentId and host name values are now properly updated on re-launch.
  • MARATHON-7654 - Marathon resident task re-launch requests are no longer denied by Mesos for having the same id as another unreachable task (because Marathon no longer re-uses task ids).

v1.4.6

10 Aug 15:07
Compare
Choose a tag to compare

Overview

Changes around unreachableStrategy

Recent changes in Apache Mesos introduced the ability to handle intermittent connectivity to an agent which may be running a Marathon task. This change introduced the TASK_UNREACHABLE. This allows for the ability for a node to disconnect and reconnect to the cluster without having a task replaced. This resulted in (based on default configurations) of a delay of 75 seconds before Marathon would be notified by Mesos to replace the task. The previous behavior of Marathon was usually sub-second replacement of a lost task.

It is now possible to configure unreachableStrategy for apps and pods to instantly replace unreachable apps or pods. To enable this behavior, you need to configure your app or pod as shown below:

{
  ...
  "unreachableStrategy": {
    "inactiveAfterSeconds": 0,
    "expungeAfterSeconds": 0
  },
  ...
}

Note: Instantly means as soon as marathon becomes aware of the unreachable task. By default, Marathon is notified after 75 seconds by Mesos
that an agent is disconnected. You can change this duration in Mesos by configuring agent_ping_timeout and max_agent_ping_timeouts.

Migrating unreachableStrategy

If you want all of your apps and pods to adopt a UnreachableStrategy that retains the previous behavior where instance were immediately replaced so that you does not have to update every single app definition.

To change the unreachableStrategy of all apps and pods, set the environment variable MIGRATION_1_4_6_UNREACHABLE_STRATEGY to true, which leads to the following behavior during migration:

When opting in to the unreachable migration step

  1. all app and pod definitions that had a config of UnreachableStrategy(300 seconds, 600 seconds) (previous default) are migrated to have UnreachableStrategy(0 seconds, 0 seconds)
  2. all app and pod definitions that had a config of UnreachableStrategy(1 second, x seconds) are migrated to have UnreachableStrategy(0 seconds, x seconds)
  3. all app and pod definitions that had a config of UnreachableStrategy(1 second, 2 seconds) are migrated to have UnreachableStrategy(0 seconds, 0 seconds)

Note: If you set this variable after upgrading to 1.4.6, it will have no effect. Also, the UnreachableStrategy default has not been changed, so in order for apps and pods created in the future to have the replace-instantly behavior, unreachableStrategy's inactiveAfterSeconds and expungeAfterSeconds must be set to 0 as seen in the JSON above.

Fixed issues

  • MARATHON-7681 - Fixes an issue in WorkQueue that could cause Marathon to drop exceptions and become unresponsive.
  • MARATHON-7653 - Fixes an issue in which Marathon could become unresponsive when pod status wasn't available
  • MARATHON-7629 - Fixes issue in which Marathon could get into an infinite kill loop, in certain situations
  • MARATHON-7469 - Fixes a bug in which a new leading Marathon would kill tasks launched by an ongoing deployment during the former leader.
  • MARATHON-7472, MARATHON-7358 - Further improve deployment performance by removing unnecessary thread blocking.
  • MARATHON-7617 - Capture storage cache layer metrics, by category
  • MARATHON-7536 - Disable HTTP TRACE method in API
  • MARATHON-7566 - Fix a regression in which content-type was required for the ping endpoint
  • MARATHON-7334 - Fix a regression in which fetch[].destPath was ignored
  • Replace lock with non-blocking concurrent data structure in WorkQueue, evidently the source of some contention looking at thread dump from MARATHON-7400
  • MARATHON-7433 - Fix a group deployment issue which would cause non-root groups without a nested group to be ignored.
  • MARATHON-7462 - Fix a race condition in WorkQueue which caused various issues, such as dropped events and could cause components of Marathon to become unresponsive.
  • MARATHON-7628 - Added agentId to the pod status
  • MARATHON-7458 - Reset root group cache when elected as leader
  • MARATHON_EE-1590 - Change unreachableStrategy to be able to start instant replacement tasks
  • MARATHON_EE-1591 - Allow migration from previous UnreachableStrategy default

v1.4.6-snap1

03 Aug 03:58
Compare
Choose a tag to compare

We're releasing v1.4.6-snap1 because we're not quite ready to land v1.4.6, and there are some fixes that many community members are anxiously awaiting.

Changes since 1.4.5

Fixed issues

  • MARATHON-7681 - Fixes an issue in WorkQueue that could cause Marathon to drop exceptions and become unresponsive.
  • MARATHON-7653 - Fixes an issue in which Marathon could become unresponsive when pod status wasn't available
  • MARATHON-7629 - Fixes issue in which Marathon could get into an infinite kill loop, in certain situations
  • MARATHON-7469 - Fixes a bug in which a new leading Marathon would kill tasks launched by an ongoing deployment during the former leader.
  • MARATHON-7472, MARATHON-7358 - Further improve deployment performance by removing unnecessary thread blocking.
  • MARATHON-7617 - Capture storage cache layer metrics, by category
  • MARATHON-7536 - Disable HTTP TRACE method in API
  • MARATHON-7566 - Fix a regression in which content-type was required for the ping endpoint
  • MARATHON-7334 - Fix a regression in which fetch[].destPath was ignored
  • Replace lock with non-blocking concurrent data structure in WorkQueue, evidently the source of some contention looking at thread dump from MARATHON-7400
  • MARATHON-7433 - Fix a group deployment issue which would cause non-root groups without a nested group to be ignored.
  • MARATHON-7462 - Fix a race condition in WorkQueue which caused various issues, such as dropped events and could cause components of Marathon to become unresponsive.

v1.4.5

15 Jun 20:54
Compare
Choose a tag to compare

Changes from 1.4.4 to 1.4.5

Fixed issues

  • MARATHON-7479 Fixes major deployment plan computation performance regression for Marathon instances containing a large number of apps (500+).

v1.4.4

07 Jun 22:13
Compare
Choose a tag to compare

Changes from 1.4.3 to 1.4.4

Changes

  • MARATHON-7411 Include USER networked docker containers in /v2/tasks text/plain output. If no host port is specified, specify address as {containerIp}:{containerPort}. If host port is specified, {agentIp}:{hostPort}.

Fixed issues

  • MARATHON-7396 Marathon leader would become a zombie process in certain Zookeper failure scenarios.
  • Marathon would not load authentication plugins in certain situations. This has been addressed.
  • MARATHON-7322 /ping endpoint returns the correct content type
  • MARATHON-7320 Fix MAX_PER constraint for attributes.
  • Fix issue related to Marathon plugins and authorization for the endpoint v2/tasks

v1.3.12

24 May 16:45
Compare
Choose a tag to compare

Changes from 1.3.11 to 1.3.12

Changes

  • MARATHON-7397 Include USER networked docker containers in /v2/tasks text/plain output. If no host port is specified, specify address as {containerIp}:{containerPort}. If host port is specified, {agentIp}:{hostPort}.

v1.3.11

18 May 10:48
Compare
Choose a tag to compare
  • dfddf50 Use the latest stable Marathon UI build (1.1.7) (#5180)

1.4.3

27 Apr 15:16
Compare
Choose a tag to compare

Changes from 1.4.2 to 1.4.3

Bugfix release

Fixed issues

  • MARATHON-7267 Enforce validation for pod container names
  • [DCOS-14890] Fix default scheme for HTTP health checks in pods
  • [DCOS-14303] Fix issue in which Marathon would fail to launch if hostname is not resolvable (but still specified from the command line)

1.4.2

27 Mar 19:00
Compare
Choose a tag to compare

Bugfix release

Fixed issues

  • MARATHON-4570 Don't destroy persistent volumes when killing unreachable tasks
  • MARATHON-4390 Lazy event parsing
  • Improve health checks to log less warnings.
  • MARATHON-1712 Loosen SSL requirements for HTTPS health checks.
  • MARATHON-1408 Fix serialization of maxSize for persistent volumes.
  • MARATHON-2311 Publish a TASK_GONE mesos update when an unreachable instance's resources are seen.
  • MARATHON-1682 Persist kill selection.
  • Disable unreachable strategy for resident tasks
  • Add a migration to fix the unreachable strategy for resident apps.
  • Read LaunchedOnReservation and ReservedTasks.
  • ForceExpunge for a missing task is a noop rather than a failure.
  • Use non-deployment-interacting kill service during kill and wipe.
  • Validation of application dependencies is too restrictive, loosed the requirements.
  • Retry failed integration tests once.
  • Fix stability in many integration tests.
  • MARATHON-7133 AppDefinition history is now properly loaded during boot

Known issues

none