Author: buildbot
Date: Tue May 19 15:41:19 2015
New Revision: 951893
Log:
Staging update by buildbot for slider
Modified:
websites/staging/slider/trunk/content/ (props changed)
websites/staging/slider/trunk/content/docs/slider_specs/application_pkg_upgrade.html
Propchange: websites/staging/slider/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Tue May 19 15:41:19 2015
@@ -1 +1 @@
-1680318
+1680321
Modified:
websites/staging/slider/trunk/content/docs/slider_specs/application_pkg_upgrade.html
==============================================================================
---
websites/staging/slider/trunk/content/docs/slider_specs/application_pkg_upgrade.html
(original)
+++
websites/staging/slider/trunk/content/docs/slider_specs/application_pkg_upgrade.html
Tue May 19 15:41:19 2015
@@ -197,24 +197,16 @@ still be the older version. Hence <code>
Automated application package upgrade will be supported soon.</p>
<h2 id="phases-of-upgradedowngrade">Phases of Upgrade/Downgrade</h2>
<h4 id="yarn-core-libraries-and-configurations-upgradedowngrade">YARN core
(libraries and configurations) upgrade/downgrade</h4>
-<blockquote>
-<p>Running Slider apps will continue to run, with no downtime</p>
-</blockquote>
+<p> Running Slider apps will continue to run, with no
downtime</p>
<h4 id="slider-client-upgradedowngrade">Slider client upgrade/downgrade</h4>
-<blockquote>
-<p>Does not affect running Slider apps at all. New version of client can
co-exist with older versions of client.</p>
-</blockquote>
+<p> Does not affect running Slider apps at all. New
version of client can co-exist with older versions of client.</p>
<h4
id="slider-application-master-upgradedowngrade-of-running-applications">Slider
Application Master upgrade/downgrade of running applications</h4>
-<blockquote>
-<p>Applications started prior to the start of YARN core upgrade/downgrade,
will continue to run with the
+<p> Applications started prior to the start of YARN
core upgrade/downgrade, will continue to run with the
older versions of Slider core and Hadoop libraries. There is no support for
rolling upgrade of Slider AM.
To upgrade running Slider AMs, the application needs to be stopped and
restarted with the new version
of the client.</p>
-</blockquote>
<h4
id="applications-deployed-by-slider-binaries-and-configurations-upgradedowngrade">Applications
deployed by Slider (binaries and configurations) upgrade/downgrade</h4>
-<blockquote>
-<p>This is the what this document is primarily about.</p>
-</blockquote>
+<p> This is the what this document is primarily
about.</p>
<h2 id="upgrade-slider-application-packages">Upgrade Slider Application
Packages</h2>
<p>A run-book style list of atomic steps exposed by Slider. These steps will
be automated
by Apache Ambari in a future release. It can be easily orchestrated by a shell
script
@@ -337,8 +329,7 @@ Master with the old v1.0 config and reso
<h2 id="pre-and-post-upgrade-hooks">Pre and post upgrade hooks</h2>
<h3 id="pre-upgrade-hook-optional">Pre-upgrade hook (optional)</h3>
-<blockquote>
-<p>The pre-upgrade steps, if provided, will allow applications to execute
simple housekeeping tasks
+<p> The pre-upgrade steps, if provided, will allow
applications to execute simple housekeeping tasks
before Slider actually calls stop operation in an upgrade scenario
(specifically if they need to
be performed in every single container and 1000s of them are running). An
example could be to
send a message to a queue that the current instance of memcached is going down
so that the load
@@ -348,20 +339,17 @@ performed manually before starting the u
pre-upgrade hook is not a good candidate for such operations. Additional
parameters might have
to be exposed, like timeout, which can be used to wait at most n seconds (say)
after which Slider
will call the application stop hook even if the pre-upgrade operation is not
completed.</p>
-<p>Use <code>app-packages/hbase/package/scripts/hbase_master.py</code> as a
sample for defining the
+<p> Use
<code>app-packages/hbase/package/scripts/hbase_master.py</code> as a sample for
defining the
pre-upgrade hook. Note, the pre-upgrade hook will be triggered only if the
currently running
application has been created using Slider verion
<code>0.80.0-incubating</code> or later and the scripts
in the package has the pre-upgrade hook defined.</p>
-</blockquote>
<h3 id="post-upgrade-hook-optional-not-yet-supported">Post-upgrade hook
(optional) - <code>not yet supported</code></h3>
-<blockquote>
-<p>This allows applications to perform simple housekeeping tasks prior to
calling start on the new
+<p> This allows applications to perform simple
housekeeping tasks prior to calling start on the new
version of the application component. This is helpful only if such tasks are
required to be
performed in every single container and 1000s of them are running. This hook
will be triggered only in the
upgrade scenario. It will not be called on new containers created using flex
up, in non-upgrade
scenarios. This makes triggering of post-upgrade hook a little tricky and
hence is not supported
today. This will be looked into, in future releases.</p>
-</blockquote>
<h2 id="upgrade-support-of-simple-apps-with-no-packages">Upgrade support of
simple apps with no packages</h2>
<ul>
<li>Upgrade of such simple apps does not involve binaries</li>
