Releases: d2iq-archive/marathon
v1.3.13
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
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
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
- all app and pod definitions that had a config of
UnreachableStrategy(300 seconds, 600 seconds)
(previous default) are migrated to haveUnreachableStrategy(0 seconds, 0 seconds)
- all app and pod definitions that had a config of
UnreachableStrategy(1 second, x seconds)
are migrated to haveUnreachableStrategy(0 seconds, x seconds)
- all app and pod definitions that had a config of
UnreachableStrategy(1 second, 2 seconds)
are migrated to haveUnreachableStrategy(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
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
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
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
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
1.4.3
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
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