You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mesos.apache.org by gi...@apache.org on 2017/12/20 14:26:43 UTC
mesos-site git commit: Updated the website built from mesos SHA:
ee621bb.
Repository: mesos-site
Updated Branches:
refs/heads/asf-site fd30cb2a4 -> a97089fb4
Updated the website built from mesos SHA: ee621bb.
Project: http://git-wip-us.apache.org/repos/asf/mesos-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/mesos-site/commit/a97089fb
Tree: http://git-wip-us.apache.org/repos/asf/mesos-site/tree/a97089fb
Diff: http://git-wip-us.apache.org/repos/asf/mesos-site/diff/a97089fb
Branch: refs/heads/asf-site
Commit: a97089fb42071b6ba2165443fe8bf371684466fb
Parents: fd30cb2
Author: jenkins <bu...@apache.org>
Authored: Wed Dec 20 14:26:41 2017 +0000
Committer: jenkins <bu...@apache.org>
Committed: Wed Dec 20 14:26:41 2017 +0000
----------------------------------------------------------------------
content/blog/feed.xml | 2 +-
.../index.html | 2 +-
content/documentation/agent-recovery/index.html | 124 ++++++++++++-------
.../latest/agent-recovery/index.html | 124 ++++++++++++-------
.../latest/configuration/agent/index.html | 18 +++
5 files changed, 180 insertions(+), 90 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/mesos-site/blob/a97089fb/content/blog/feed.xml
----------------------------------------------------------------------
diff --git a/content/blog/feed.xml b/content/blog/feed.xml
index 3801975..c1e2cad 100644
--- a/content/blog/feed.xml
+++ b/content/blog/feed.xml
@@ -168,7 +168,7 @@ To learn more about CSI work in Mesos, you can dig into the design document <
</ul>
-<p>If you are a user and would like to suggest some areas for performance improvement, please let us know by emailing <a href="&#109;&#97;&#x69;&#108;&#116;&#111;&#x3a;&#100;&#x65;&#118;&#64;&#x61;&#112;&#97;&#99;&#104;&#101;&#x2e;&#x6d;&#x65;&#x73;&#x6f;&#x73;&#46;&#x6f;&#114;&#x67;">&#x64;&#x65;&#x76;&#x40;&#97;&#x70;&#97;&#99;&#x68;&#101;&#x2e;&#x6d;&#x65;&#x73;&#x6f;&#115;&#x2e;&#x6f;&#x72;&#x67;</a>.</p>
+<p>If you are a user and would like to suggest some areas for performance improvement, please let us know by emailing <a href="&#109;&#x61;&#105;&#x6c;&#116;&#x6f;&#x3a;&#100;&#x65;&#118;&#64;&#x61;&#x70;&#x61;&#99;&#104;&#x65;&#x2e;&#109;&#x65;&#x73;&#x6f;&#x73;&#46;&#x6f;&#114;&#x67;">&#x64;&#101;&#x76;&#64;&#x61;&#x70;&#97;&#99;&#x68;&#x65;&#x2e;&#x6d;&#101;&#x73;&#x6f;&#x73;&#46;&#111;&#x72;&#103;</a>.</p>
</content>
</entry>
http://git-wip-us.apache.org/repos/asf/mesos-site/blob/a97089fb/content/blog/performance-working-group-progress-report/index.html
----------------------------------------------------------------------
diff --git a/content/blog/performance-working-group-progress-report/index.html b/content/blog/performance-working-group-progress-report/index.html
index 679cad3..b0e8d60 100644
--- a/content/blog/performance-working-group-progress-report/index.html
+++ b/content/blog/performance-working-group-progress-report/index.html
@@ -248,7 +248,7 @@
</ul>
-<p>If you are a user and would like to suggest some areas for performance improvement, please let us know by emailing <a href="mailto:dev@apache.mesos.org">dev@apache.mesos.org</a>.</p>
+<p>If you are a user and would like to suggest some areas for performance improvement, please let us know by emailing <a href="mailto:dev@apache.mesos.org">dev@apache.mesos.org</a>.</p>
</div>
</div>
http://git-wip-us.apache.org/repos/asf/mesos-site/blob/a97089fb/content/documentation/agent-recovery/index.html
----------------------------------------------------------------------
diff --git a/content/documentation/agent-recovery/index.html b/content/documentation/agent-recovery/index.html
index 95001dd..f6a5865 100644
--- a/content/documentation/agent-recovery/index.html
+++ b/content/documentation/agent-recovery/index.html
@@ -118,88 +118,124 @@
<p>If the <code>mesos-agent</code> process on a host exits (perhaps due to a Mesos bug or
because the operator kills the process while <a href="/documentation/latest/./upgrades/">upgrading Mesos</a>),
any executors/tasks that were being managed by the <code>mesos-agent</code> process will
-continue to run. When <code>mesos-agent</code> is restarted, the operator can control how
-those old executors/tasks are handled:</p>
+continue to run.</p>
-<ol>
-<li>By default, all the executors/tasks that were being managed by the old
-<code>mesos-agent</code> process are killed.</li>
-<li>If a framework enabled <em>checkpointing</em> when it registered with the master,
-any executors belonging to that framework can reconnect to the new
-<code>mesos-agent</code> process and continue running uninterrupted.</li>
-</ol>
+<p>By default, all the executors/tasks that were being managed by the old
+<code>mesos-agent</code> process are expected to gracefully exit on their own, and
+will be shut down after the agent restarted if they did not.</p>
+<p>However, if a framework enabled <em>checkpointing</em> when it registered with the
+master, any executors belonging to that framework can reconnect to the new
+<code>mesos-agent</code> process and continue running uninterrupted. Hence, enabling
+framework checkpointing allows tasks to tolerate Mesos agent upgrades and
+unexpected <code>mesos-agent</code> crashes without experiencing any downtime.</p>
-<p>Hence, enabling framework checkpointing enables tasks to tolerate Mesos agent
-upgrades and unexpected <code>mesos-agent</code> crashes without experiencing any
-downtime.</p>
+<p>Agent recovery works by having the agent checkpoint information about its own
+state and about the tasks and executors it is managing to local disk, for
+example the <code>SlaveInfo</code>, <code>FrameworkInfo</code> and <code>ExecutorInfo</code> messages or the
+unacknowledged status updates of running tasks.</p>
-<p>Agent recovery works by having the agent <em>checkpoint</em> information (e.g., Task
-Info, Executor Info, Status Updates) about the tasks and executors it is
-managing to local disk. If a framework enables checkpointing, any subsequent
-agent restarts will recover the checkpointed information and reconnect with any
-executors that are still running.</p>
+<p>When the agent restarts, it will verify that its current configuration, set
+from the environment variables and command-line flags, is compatible with the
+checkpointed information and will refuse to restart if not.</p>
-<p>Note that if the operating system on the agent is rebooted, all executors and
-tasks running on the host are killed and are not automatically restarted when
-the host comes back up.</p>
+<p>A special case occurs when the agent detects that its host system was rebooted
+since the last run of the agent: The agent will try to recover its previous ID
+as usual, but if that fails it will actually erase the information of the
+previous run and will register with the master as a new agent.</p>
-<p>However the agent is allowed to recover its agent ID post a host reboot.
-In case the agent’s recovery runs into agent info mismatch which may happen due to resource change associated with reboot, it’ll fall back to recovering as a new agent (existing behavior).
-In other cases such as checkpointed resources (e.g. persistent volumes) being incompatible with the agent’s resources the recovery will still fail (existing behavior).</p>
+<p>Note that executors and tasks that exited between agent shutdown and restart
+are not automatically restarted during agent recovery.</p>
<h2>Framework Configuration</h2>
-<p>A framework can control whether its executors will be recovered by setting the <code>checkpoint</code> flag in its <code>FrameworkInfo</code> when registering with the master. Enabling this feature results in increased I/O overhead at each agent that runs tasks launched by the framework. By default, frameworks do <strong>not</strong> checkpoint their state.</p>
+<p>A framework can control whether its executors will be recovered by setting
+the <code>checkpoint</code> flag in its <code>FrameworkInfo</code> when registering with the master.
+Enabling this feature results in increased I/O overhead at each agent that runs
+tasks launched by the framework. By default, frameworks do <strong>not</strong> checkpoint
+their state.</p>
<h2>Agent Configuration</h2>
-<p>Three <a href="/documentation/latest/./configuration/agent/">configuration flags</a> control the recovery behavior of a Mesos agent:</p>
+<p>Four <a href="/documentation/latest/./configuration/agent/">configuration flags</a> control the recovery
+behavior of a Mesos agent:</p>
<ul>
<li><p><code>strict</code>: Whether to do agent recovery in strict mode [Default: true].</p>
<ul>
<li>If strict=true, all recovery errors are considered fatal.</li>
-<li>If strict=false, any errors (e.g., corruption in checkpointed data) during recovery are
-ignored and as much state as possible is recovered.</li>
+<li>If strict=false, any errors (e.g., corruption in checkpointed data) during
+recovery are ignored and as much state as possible is recovered.</li>
</ul>
</li>
-<li><p><code>recover</code>: Whether to recover status updates and reconnect with old executors [Default: reconnect].</p>
+<li><p><code>reconfiguration_policy</code>: Which kind of configuration changes are accepted
+when trying to recover [Default: equal].</p>
<ul>
-<li>If recover=reconnect, reconnect with any old live executors, provided the executor’s framework enabled checkpointing.</li>
-<li>If recover=cleanup, kill any old live executors and exit. Use this option when doing an incompatible agent or executor upgrade!
+<li>If reconfiguration_policy=equal, no configuration changes are accepted.</li>
+<li>If reconfiguration_policy=additive, the agent will allow the new
+configuration to contain additional attributes, increased resourced or an
+additional fault domain. For a more detailed description, see
+<a href="https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob;f=src/slave/compatibility.hpp;h=78b421a01abe5d2178c93832577577a7ba282b38;hb=HEAD#l37">this</a>.</li>
+</ul>
+</li>
+<li><p><code>recover</code>: Whether to recover status updates and reconnect with old
+executors [Default: reconnect]</p>
-<blockquote><p>NOTE: If no checkpointing information exists, no recovery is performed
-and the agent registers with the master as a new agent.</p></blockquote></li>
+<ul>
+<li>If recover=reconnect, reconnect with any old live executors, provided
+the executor’s framework enabled checkpointing.</li>
+<li>If recover=cleanup, kill any old live executors and exit. Use this
+option when doing an incompatible agent or executor upgrade!
+<strong>NOTE:</strong> If no checkpointing information exists, no recovery is performed
+and the agent registers with the master as a new agent.</li>
</ul>
</li>
-<li><p><code>recovery_timeout</code>: Amount of time allotted for the agent to recover [Default: 15 mins].</p>
+<li><p><code>recovery_timeout</code>: Amount of time allotted for the agent to
+recover [Default: 15 mins].</p>
<ul>
-<li>If the agent takes longer than <code>recovery_timeout</code> to recover, any executors that are waiting to
-reconnect to the agent will self-terminate.</li>
+<li>If the agent takes longer than <code>recovery_timeout</code> to recover, any
+executors that are waiting to reconnect to the agent will self-terminate.
+<strong>NOTE:</strong> If none of the frameworks have enabled checkpointing, the
+executors and tasks running at an agent die when the agent dies and are
+not recovered.</li>
</ul>
</li>
</ul>
-<blockquote><p>NOTE: If none of the frameworks have enabled checkpointing,
-the executors and tasks running at an agent die when the agent dies
-and are not recovered.</p></blockquote>
+<p>A restarted agent should re-register with master within a timeout (75 seconds
+by default: see the <code>--max_agent_ping_timeouts</code> and <code>--agent_ping_timeout</code>
+<a href="/documentation/latest/./configuration/">configuration flags</a>). If the agent takes longer than this
+timeout to re-register, the master shuts down the agent, which in turn will
+shutdown any live executors/tasks.</p>
-<p>A restarted agent should re-register with master within a timeout (75 seconds by default: see the <code>--max_agent_ping_timeouts</code> and <code>--agent_ping_timeout</code> <a href="/documentation/latest/./configuration/">configuration flags</a>). If the agent takes longer than this timeout to re-register, the master shuts down the agent, which in turn will shutdown any live executors/tasks. Therefore, it is highly recommended to automate the process of restarting an agent (e.g., using a process supervisor such as <a href="http://mmonit.com/monit/">monit</a> or <code>systemd</code>).</p>
+<p>Therefore, it is highly recommended to automate the process of restarting an
+agent, e.g. using a process supervisor such as <a href="http://mmonit.com/monit/">monit</a>
+or <code>systemd</code>.</p>
<h2>Known issues with <code>systemd</code> and process lifetime</h2>
-<p>There is a known issue when using <code>systemd</code> to launch the <code>mesos-agent</code>. A description of the problem can be found in <a href="https://issues.apache.org/jira/browse/MESOS-3425">MESOS-3425</a> and all relevant work can be tracked in the epic <a href="https://issues.apache.org/jira/browse/MESOS-3007">MESOS-3007</a>.
-This problem was fixed in Mesos <code>0.25.0</code> for the mesos containerizer when cgroups isolation is enabled. Further fixes for the posix isolators and docker containerizer are available in <code>0.25.1</code>, <code>0.26.1</code>, <code>0.27.1</code>, and <code>0.28.0</code>.</p>
+<p>There is a known issue when using <code>systemd</code> to launch the <code>mesos-agent</code>. A
+description of the problem can be found in <a href="https://issues.apache.org/jira/browse/MESOS-3425">MESOS-3425</a>
+and all relevant work can be tracked in the epic <a href="https://issues.apache.org/jira/browse/MESOS-3007">MESOS-3007</a>.</p>
+
+<p>This problem was fixed in Mesos <code>0.25.0</code> for the mesos containerizer when
+cgroups isolation is enabled. Further fixes for the posix isolators and docker
+containerizer are available in <code>0.25.1</code>, <code>0.26.1</code>, <code>0.27.1</code>, and <code>0.28.0</code>.</p>
-<p>It is recommended that you use the default <a href="http://www.freedesktop.org/software/systemd/man/systemd.kill.html">KillMode</a> for systemd processes, which is <code>control-group</code>, which kills all child processes when the agent stops. This ensures that “side-car” processes such as the <code>fetcher</code> and <code>perf</code> are terminated alongside the agent.
-The systemd patches for Mesos explicitly move executors and their children into a separate systemd slice, dissociating their lifetime from the agent. This ensures the executors survive agent restarts.</p>
+<p>It is recommended that you use the default <a href="http://www.freedesktop.org/software/systemd/man/systemd.kill.html">KillMode</a>
+for systemd processes, which is <code>control-group</code>, which kills all child processes
+when the agent stops. This ensures that “side-car” processes such as the
+<code>fetcher</code> and <code>perf</code> are terminated alongside the agent.
+The systemd patches for Mesos explicitly move executors and their children into
+a separate systemd slice, dissociating their lifetime from the agent. This
+ensures the executors survive agent restarts.</p>
-<p>The following excerpt of a <code>systemd</code> unit configuration file shows how to set the flag explicitly:</p>
+<p>The following excerpt of a <code>systemd</code> unit configuration file shows how to set
+the flag explicitly:</p>
<pre><code>[Service]
ExecStart=/usr/bin/mesos-agent
http://git-wip-us.apache.org/repos/asf/mesos-site/blob/a97089fb/content/documentation/latest/agent-recovery/index.html
----------------------------------------------------------------------
diff --git a/content/documentation/latest/agent-recovery/index.html b/content/documentation/latest/agent-recovery/index.html
index f30eebc..f18b43d 100644
--- a/content/documentation/latest/agent-recovery/index.html
+++ b/content/documentation/latest/agent-recovery/index.html
@@ -118,88 +118,124 @@
<p>If the <code>mesos-agent</code> process on a host exits (perhaps due to a Mesos bug or
because the operator kills the process while <a href="/documentation/latest/./upgrades/">upgrading Mesos</a>),
any executors/tasks that were being managed by the <code>mesos-agent</code> process will
-continue to run. When <code>mesos-agent</code> is restarted, the operator can control how
-those old executors/tasks are handled:</p>
+continue to run.</p>
-<ol>
-<li>By default, all the executors/tasks that were being managed by the old
-<code>mesos-agent</code> process are killed.</li>
-<li>If a framework enabled <em>checkpointing</em> when it registered with the master,
-any executors belonging to that framework can reconnect to the new
-<code>mesos-agent</code> process and continue running uninterrupted.</li>
-</ol>
+<p>By default, all the executors/tasks that were being managed by the old
+<code>mesos-agent</code> process are expected to gracefully exit on their own, and
+will be shut down after the agent restarted if they did not.</p>
+<p>However, if a framework enabled <em>checkpointing</em> when it registered with the
+master, any executors belonging to that framework can reconnect to the new
+<code>mesos-agent</code> process and continue running uninterrupted. Hence, enabling
+framework checkpointing allows tasks to tolerate Mesos agent upgrades and
+unexpected <code>mesos-agent</code> crashes without experiencing any downtime.</p>
-<p>Hence, enabling framework checkpointing enables tasks to tolerate Mesos agent
-upgrades and unexpected <code>mesos-agent</code> crashes without experiencing any
-downtime.</p>
+<p>Agent recovery works by having the agent checkpoint information about its own
+state and about the tasks and executors it is managing to local disk, for
+example the <code>SlaveInfo</code>, <code>FrameworkInfo</code> and <code>ExecutorInfo</code> messages or the
+unacknowledged status updates of running tasks.</p>
-<p>Agent recovery works by having the agent <em>checkpoint</em> information (e.g., Task
-Info, Executor Info, Status Updates) about the tasks and executors it is
-managing to local disk. If a framework enables checkpointing, any subsequent
-agent restarts will recover the checkpointed information and reconnect with any
-executors that are still running.</p>
+<p>When the agent restarts, it will verify that its current configuration, set
+from the environment variables and command-line flags, is compatible with the
+checkpointed information and will refuse to restart if not.</p>
-<p>Note that if the operating system on the agent is rebooted, all executors and
-tasks running on the host are killed and are not automatically restarted when
-the host comes back up.</p>
+<p>A special case occurs when the agent detects that its host system was rebooted
+since the last run of the agent: The agent will try to recover its previous ID
+as usual, but if that fails it will actually erase the information of the
+previous run and will register with the master as a new agent.</p>
-<p>However the agent is allowed to recover its agent ID post a host reboot.
-In case the agent’s recovery runs into agent info mismatch which may happen due to resource change associated with reboot, it’ll fall back to recovering as a new agent (existing behavior).
-In other cases such as checkpointed resources (e.g. persistent volumes) being incompatible with the agent’s resources the recovery will still fail (existing behavior).</p>
+<p>Note that executors and tasks that exited between agent shutdown and restart
+are not automatically restarted during agent recovery.</p>
<h2>Framework Configuration</h2>
-<p>A framework can control whether its executors will be recovered by setting the <code>checkpoint</code> flag in its <code>FrameworkInfo</code> when registering with the master. Enabling this feature results in increased I/O overhead at each agent that runs tasks launched by the framework. By default, frameworks do <strong>not</strong> checkpoint their state.</p>
+<p>A framework can control whether its executors will be recovered by setting
+the <code>checkpoint</code> flag in its <code>FrameworkInfo</code> when registering with the master.
+Enabling this feature results in increased I/O overhead at each agent that runs
+tasks launched by the framework. By default, frameworks do <strong>not</strong> checkpoint
+their state.</p>
<h2>Agent Configuration</h2>
-<p>Three <a href="/documentation/latest/./configuration/agent/">configuration flags</a> control the recovery behavior of a Mesos agent:</p>
+<p>Four <a href="/documentation/latest/./configuration/agent/">configuration flags</a> control the recovery
+behavior of a Mesos agent:</p>
<ul>
<li><p><code>strict</code>: Whether to do agent recovery in strict mode [Default: true].</p>
<ul>
<li>If strict=true, all recovery errors are considered fatal.</li>
-<li>If strict=false, any errors (e.g., corruption in checkpointed data) during recovery are
-ignored and as much state as possible is recovered.</li>
+<li>If strict=false, any errors (e.g., corruption in checkpointed data) during
+recovery are ignored and as much state as possible is recovered.</li>
</ul>
</li>
-<li><p><code>recover</code>: Whether to recover status updates and reconnect with old executors [Default: reconnect].</p>
+<li><p><code>reconfiguration_policy</code>: Which kind of configuration changes are accepted
+when trying to recover [Default: equal].</p>
<ul>
-<li>If recover=reconnect, reconnect with any old live executors, provided the executor’s framework enabled checkpointing.</li>
-<li>If recover=cleanup, kill any old live executors and exit. Use this option when doing an incompatible agent or executor upgrade!
+<li>If reconfiguration_policy=equal, no configuration changes are accepted.</li>
+<li>If reconfiguration_policy=additive, the agent will allow the new
+configuration to contain additional attributes, increased resourced or an
+additional fault domain. For a more detailed description, see
+<a href="https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob;f=src/slave/compatibility.hpp;h=78b421a01abe5d2178c93832577577a7ba282b38;hb=HEAD#l37">this</a>.</li>
+</ul>
+</li>
+<li><p><code>recover</code>: Whether to recover status updates and reconnect with old
+executors [Default: reconnect]</p>
-<blockquote><p>NOTE: If no checkpointing information exists, no recovery is performed
-and the agent registers with the master as a new agent.</p></blockquote></li>
+<ul>
+<li>If recover=reconnect, reconnect with any old live executors, provided
+the executor’s framework enabled checkpointing.</li>
+<li>If recover=cleanup, kill any old live executors and exit. Use this
+option when doing an incompatible agent or executor upgrade!
+<strong>NOTE:</strong> If no checkpointing information exists, no recovery is performed
+and the agent registers with the master as a new agent.</li>
</ul>
</li>
-<li><p><code>recovery_timeout</code>: Amount of time allotted for the agent to recover [Default: 15 mins].</p>
+<li><p><code>recovery_timeout</code>: Amount of time allotted for the agent to
+recover [Default: 15 mins].</p>
<ul>
-<li>If the agent takes longer than <code>recovery_timeout</code> to recover, any executors that are waiting to
-reconnect to the agent will self-terminate.</li>
+<li>If the agent takes longer than <code>recovery_timeout</code> to recover, any
+executors that are waiting to reconnect to the agent will self-terminate.
+<strong>NOTE:</strong> If none of the frameworks have enabled checkpointing, the
+executors and tasks running at an agent die when the agent dies and are
+not recovered.</li>
</ul>
</li>
</ul>
-<blockquote><p>NOTE: If none of the frameworks have enabled checkpointing,
-the executors and tasks running at an agent die when the agent dies
-and are not recovered.</p></blockquote>
+<p>A restarted agent should re-register with master within a timeout (75 seconds
+by default: see the <code>--max_agent_ping_timeouts</code> and <code>--agent_ping_timeout</code>
+<a href="/documentation/latest/./configuration/">configuration flags</a>). If the agent takes longer than this
+timeout to re-register, the master shuts down the agent, which in turn will
+shutdown any live executors/tasks.</p>
-<p>A restarted agent should re-register with master within a timeout (75 seconds by default: see the <code>--max_agent_ping_timeouts</code> and <code>--agent_ping_timeout</code> <a href="/documentation/latest/./configuration/">configuration flags</a>). If the agent takes longer than this timeout to re-register, the master shuts down the agent, which in turn will shutdown any live executors/tasks. Therefore, it is highly recommended to automate the process of restarting an agent (e.g., using a process supervisor such as <a href="http://mmonit.com/monit/">monit</a> or <code>systemd</code>).</p>
+<p>Therefore, it is highly recommended to automate the process of restarting an
+agent, e.g. using a process supervisor such as <a href="http://mmonit.com/monit/">monit</a>
+or <code>systemd</code>.</p>
<h2>Known issues with <code>systemd</code> and process lifetime</h2>
-<p>There is a known issue when using <code>systemd</code> to launch the <code>mesos-agent</code>. A description of the problem can be found in <a href="https://issues.apache.org/jira/browse/MESOS-3425">MESOS-3425</a> and all relevant work can be tracked in the epic <a href="https://issues.apache.org/jira/browse/MESOS-3007">MESOS-3007</a>.
-This problem was fixed in Mesos <code>0.25.0</code> for the mesos containerizer when cgroups isolation is enabled. Further fixes for the posix isolators and docker containerizer are available in <code>0.25.1</code>, <code>0.26.1</code>, <code>0.27.1</code>, and <code>0.28.0</code>.</p>
+<p>There is a known issue when using <code>systemd</code> to launch the <code>mesos-agent</code>. A
+description of the problem can be found in <a href="https://issues.apache.org/jira/browse/MESOS-3425">MESOS-3425</a>
+and all relevant work can be tracked in the epic <a href="https://issues.apache.org/jira/browse/MESOS-3007">MESOS-3007</a>.</p>
+
+<p>This problem was fixed in Mesos <code>0.25.0</code> for the mesos containerizer when
+cgroups isolation is enabled. Further fixes for the posix isolators and docker
+containerizer are available in <code>0.25.1</code>, <code>0.26.1</code>, <code>0.27.1</code>, and <code>0.28.0</code>.</p>
-<p>It is recommended that you use the default <a href="http://www.freedesktop.org/software/systemd/man/systemd.kill.html">KillMode</a> for systemd processes, which is <code>control-group</code>, which kills all child processes when the agent stops. This ensures that “side-car” processes such as the <code>fetcher</code> and <code>perf</code> are terminated alongside the agent.
-The systemd patches for Mesos explicitly move executors and their children into a separate systemd slice, dissociating their lifetime from the agent. This ensures the executors survive agent restarts.</p>
+<p>It is recommended that you use the default <a href="http://www.freedesktop.org/software/systemd/man/systemd.kill.html">KillMode</a>
+for systemd processes, which is <code>control-group</code>, which kills all child processes
+when the agent stops. This ensures that “side-car” processes such as the
+<code>fetcher</code> and <code>perf</code> are terminated alongside the agent.
+The systemd patches for Mesos explicitly move executors and their children into
+a separate systemd slice, dissociating their lifetime from the agent. This
+ensures the executors survive agent restarts.</p>
-<p>The following excerpt of a <code>systemd</code> unit configuration file shows how to set the flag explicitly:</p>
+<p>The following excerpt of a <code>systemd</code> unit configuration file shows how to set
+the flag explicitly:</p>
<pre><code>[Service]
ExecStart=/usr/bin/mesos-agent
http://git-wip-us.apache.org/repos/asf/mesos-site/blob/a97089fb/content/documentation/latest/configuration/agent/index.html
----------------------------------------------------------------------
diff --git a/content/documentation/latest/configuration/agent/index.html b/content/documentation/latest/configuration/agent/index.html
index bd34aff..49514cc 100644
--- a/content/documentation/latest/configuration/agent/index.html
+++ b/content/documentation/latest/configuration/agent/index.html
@@ -1158,6 +1158,24 @@ this flag. (default: 0secs)
</tr>
<tr>
<td>
+ --reconfiguration_policy=VALUE
+ </td>
+ <td>
+This flag controls which agent configuration changes are considered
+acceptable when recovering the previous agent state. Possible values:
+ equal: The old and the new state must match exactly.
+ additive: The new state must be a superset of the old state:
+ it is permitted to add additional resources, attributes
+ and domains but not to remove or to modify existing ones.
+
+Note that this only affects the checking done on the agent itself,
+the master may still reject the agent if it detects a change that it
+considers unacceptable, which, e.g., currently happens when port or hostname
+are changed. (default: equal)
+ </td>
+</tr>
+<tr>
+ <td>
--recover=VALUE
</td>
<td>