aurora-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dles...@apache.org
Subject svn commit: r1651176 - in /incubator/aurora/site: publish/documentation/latest/ publish/documentation/latest/client-commands/ publish/documentation/latest/clientv2/ publish/documentation/latest/contributing/ publish/documentation/latest/cron-jobs/ publ...
Date Mon, 12 Jan 2015 19:37:50 GMT
Author: dlester
Date: Mon Jan 12 19:37:50 2015
New Revision: 1651176

URL: http://svn.apache.org/r1651176
Log:
Update Apache Aurora website documentation.

Removed:
    incubator/aurora/site/publish/documentation/latest/clientv2/
    incubator/aurora/site/source/documentation/latest/clientv2.md
Modified:
    incubator/aurora/site/publish/documentation/latest/client-commands/index.html
    incubator/aurora/site/publish/documentation/latest/contributing/index.html
    incubator/aurora/site/publish/documentation/latest/cron-jobs/index.html
    incubator/aurora/site/publish/documentation/latest/developing-aurora-client/index.html
    incubator/aurora/site/publish/documentation/latest/index.html
    incubator/aurora/site/publish/documentation/latest/tutorial/index.html
    incubator/aurora/site/publish/documentation/latest/user-guide/index.html
    incubator/aurora/site/source/documentation/latest.html.md
    incubator/aurora/site/source/documentation/latest/client-commands.md
    incubator/aurora/site/source/documentation/latest/contributing.md
    incubator/aurora/site/source/documentation/latest/cron-jobs.md
    incubator/aurora/site/source/documentation/latest/developing-aurora-client.md
    incubator/aurora/site/source/documentation/latest/tutorial.md
    incubator/aurora/site/source/documentation/latest/user-guide.md

Modified: incubator/aurora/site/publish/documentation/latest/client-commands/index.html
URL: http://svn.apache.org/viewvc/incubator/aurora/site/publish/documentation/latest/client-commands/index.html?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/publish/documentation/latest/client-commands/index.html (original)
+++ incubator/aurora/site/publish/documentation/latest/client-commands/index.html Mon Jan 12 19:37:50 2015
@@ -41,12 +41,6 @@
 <h5 class="page-header text-uppercase">Documentation</h5>
 <h1 id="aurora-client-commands">Aurora Client Commands</h1>
 
-<p>The most up-to-date reference is in the client itself: use the
-<code>aurora help</code> subcommand (for example, <code>aurora help</code> or
-<code>aurora help create</code>) to find the latest information on parameters and
-functionality. Note that <code>aurora help open</code> does not work, due to underlying issues with
-reflection.</p>
-
 <ul>
 <li><a href="#introduction">Introduction</a></li>
 <li><a href="#cluster-configuration">Cluster Configuration</a></li>
@@ -170,11 +164,11 @@ the machine executing Aurora commands.</
 <p>Hooks can be associated with these Aurora Client commands.</p>
 
 <ul>
-<li><code>cancel_update</code></li>
-<li><code>create</code></li>
-<li><code>kill</code></li>
-<li><code>restart</code></li>
-<li><code>update</code></li>
+<li><code>job cancel-update</code></li>
+<li><code>job create</code></li>
+<li><code>job kill</code></li>
+<li><code>job restart</code></li>
+<li><code>job update</code></li>
 </ul>
 
 <p>The process for writing and activating them is complex enough
@@ -186,29 +180,13 @@ that we explain it in a devoted document
 renaming, updating, and restarting a basic Aurora Job.</p>
 
 <h3 id="creating-and-running-a-job">Creating and Running a Job</h3>
-<pre class="highlight text">aurora create &lt;job key&gt; &lt;configuration file&gt;
+<pre class="highlight text">aurora job create &lt;job key&gt; &lt;configuration file&gt;
 </pre>
 <p>Creates and then runs a Job with the specified job key based on a <code>.aurora</code> configuration file.
 The configuration file may also contain and activate hook definitions.</p>
 
-<p><code>create</code> can take four named parameters:</p>
-
-<ul>
-<li><code>-E NAME=VALUE</code> Bind a Thermos mustache variable name to a
-value. Multiple flags specify multiple values. Defaults to <code>[]</code>.</li>
-<li><code>-o, --open_browser</code> Open a browser window to the scheduler UI Job
-page after a job changing operation happens. When <code>False</code>, the Job
-URL prints on the console and the user has to copy/paste it
-manually. Defaults to <code>False</code>. Does not work when running in Vagrant.</li>
-<li><code>-j, --json</code> If specified, configuration argument is read as a
-string in JSON format. Defaults to False.</li>
-<li><code>--wait_until=STATE</code> Block the client until all the Tasks have
-transitioned into the requested state. Possible values are: <code>PENDING</code>,
-<code>RUNNING</code>, <code>FINISHED</code>. Default: <code>PENDING</code></li>
-</ul>
-
 <h3 id="running-a-command-on-a-running-job">Running a Command On a Running Job</h3>
-<pre class="highlight text">aurora run &lt;job_key&gt; &lt;cmd&gt;
+<pre class="highlight text">aurora task run CLUSTER/ROLE/ENV/NAME[/INSTANCES] &lt;cmd&gt;
 </pre>
 <p>Runs a shell command on all machines currently hosting shards of a
 single Job.</p>
@@ -217,79 +195,40 @@ single Job.</p>
 commands; i.e. anything in the <code>{{mesos.*}}</code> and <code>{{thermos.*}}</code>
 namespaces.</p>
 
-<p><code>run</code> can take three named parameters:</p>
-
-<ul>
-<li><code>-t NUM_THREADS</code>, <code>--threads=NUM_THREADS</code>The number of threads to
-use, defaulting to <code>1</code>.</li>
-<li><code>--user=SSH_USER</code> ssh as this user instead of the given role value.
-Defaults to None.</li>
-<li><code>-e, --executor_sandbox</code>  Run the command in the executor sandbox
-instead of the Task sandbox. Defaults to False.</li>
-</ul>
-
 <h3 id="killing-a-job">Killing a Job</h3>
-<pre class="highlight text">aurora kill &lt;job key&gt; &lt;configuration file&gt;
+<pre class="highlight text">aurora job killall CLUSTER/ROLE/ENV/NAME
 </pre>
 <p>Kills all Tasks associated with the specified Job, blocking until all
-are terminated. Defaults to killing all shards in the Job.</p>
+are terminated. Defaults to killing all instances in the Job.</p>
 
 <p>The <code>&lt;configuration file&gt;</code> argument for <code>kill</code> is optional. Use it only
 if it contains hook definitions and activations that affect the
 kill command.</p>
 
-<p><code>kill</code> can take two named parameters:</p>
-
-<ul>
-<li><code>-o, --open_browser</code> Open a browser window to the scheduler UI Job
-page after a job changing operation happens. When <code>False</code>, the Job
-URL prints on the console and the user has to copy/paste it
-manually. Defaults to <code>False</code>. Does not work when running in Vagrant.</li>
-<li><code>--shards=SHARDS</code> A list of shard ids to act on. Can either be a
-comma-separated list (e.g. 0,1,2) or a range (e.g. 0-2) or  any
-combination of the two (e.g. 0-2,5,7-9). Defaults to acting on all
-shards.</li>
-</ul>
-
 <h3 id="updating-a-job">Updating a Job</h3>
-<pre class="highlight text">aurora update [--shards=ids] &lt;job key&gt; &lt;configuration file&gt;
-aurora cancel_update &lt;job key&gt; &lt;configuration file&gt;
+<pre class="highlight text">aurora job update CLUSTER/ROLE/ENV/NAME[/INSTANCES] &lt;configuration file&gt;
+aurora job cancel-update CLUSTER/ROLE/ENV/NAME
 </pre>
 <p>Given a running job, does a rolling update to reflect a new
 configuration version. Only updates Tasks in the Job with a changed
-configuration. You can further restrict the operated on Tasks by
-using <code>--shards</code> and specifying a comma-separated list of job shard ids.</p>
+configuration. You can further restrict the operated on Tasks by specifying
+specific instances that should be updated.</p>
 
-<p>You may want to run <code>aurora diff</code> beforehand to validate which Tasks
+<p>You may want to run <code>aurora job diff</code> beforehand to validate which Tasks
 have different configurations.</p>
 
 <p>Updating jobs are locked to be sure the update finishes without
 disruption. If the update abnormally terminates, the lock may stay
 around and cause failure of subsequent update attempts.
- <code>aurora cancel_update</code>unlocks the Job specified by
-its <code>job_key</code> argument. Be sure you don&rsquo;t issue <code>cancel_update</code> when
+ <code>aurora job cancel-update</code>unlocks the Job specified by
+its <code>job_key</code> argument. Be sure you don&rsquo;t issue <code>job cancel-update</code> when
 another user is working with the specified Job.</p>
 
-<p>The <code>&lt;configuration file&gt;</code> argument for <code>cancel_update</code> is optional. Use
+<p>The <code>&lt;configuration file&gt;</code> argument for <code>job cancel-update</code> is optional. Use
 it only if it contains hook definitions and activations that affect the
 <code>cancel_update</code> command. The <code>&lt;configuration file&gt;</code> argument for
 <code>update</code> is required, but in addition to a new configuration it can be
-used to define and activate hooks for <code>update</code>.</p>
-
-<p><code>update</code> can take four named parameters:</p>
-
-<ul>
-<li><code>--shards=SHARDS</code> A list of shard ids to update. Can either be a
-comma-separated list (e.g. 0,1,2) or a range (e.g. 0-2) or  any
-combination of the two (e.g. 0-2,5,7-9). If not  set, all shards are
-acted on. Defaults to None.</li>
-<li><code>-E NAME=VALUE</code> Binds a Thermos mustache variable name to a value.
-Use multiple flags to specify multiple values. Defaults to <code>[]</code>.</li>
-<li><code>-j, --json</code> If specified, configuration is read in JSON format.
-Defaults to <code>False</code>.</li>
-<li><code>--updater_health_check_interval_seconds=HEALTH_CHECK_INTERVAL_SECONDS</code>
-Time interval between subsequent shard status checks. Defaults to <code>3</code>.</li>
-</ul>
+used to define and activate hooks for <code>job update</code>.</p>
 
 <h4 id="asynchronous-job-updates-(beta)">Asynchronous job updates (beta)</h4>
 
@@ -298,12 +237,12 @@ scheduler. Performing updates this way a
 update progress and job update history in the browser.</p>
 
 <p>There are several sub-commands to manage job updates:</p>
-<pre class="highlight text">aurora2 beta-update start &lt;job key&gt; &lt;configuration file
-aurora2 beta-update status &lt;job key&gt;
-aurora2 beta-update pause &lt;job key&gt;
-aurora2 beta-update resume &lt;job key&gt;
-aurora2 beta-update abort &lt;job key&gt;
-aurora2 beta-update list &lt;cluster&gt;
+<pre class="highlight text">aurora beta-update start &lt;job key&gt; &lt;configuration file&gt;
+aurora beta-update status &lt;job key&gt;
+aurora beta-update pause &lt;job key&gt;
+aurora beta-update resume &lt;job key&gt;
+aurora beta-update abort &lt;job key&gt;
+aurora beta-update list &lt;cluster&gt;
 </pre>
 <p>When you <code>start</code> a job update, the command will return once it has sent the
 instructions to the scheduler.  At that point, you may view detailed
@@ -332,18 +271,18 @@ environment, and/or name as appropriate
 scheme.</li>
 <li><p>Check that only these naming components have changed
 with <code>aurora diff</code>.</p>
-<pre class="highlight text">aurora diff &lt;job_key&gt; &lt;job_configuration&gt;
+<pre class="highlight text">aurora job diff CLUSTER/ROLE/ENV/NAME &lt;job_configuration&gt;
 </pre></li>
 <li><p>Create the (identical) job at the new key. You may need to request a
 temporary quota increase.</p>
-<pre class="highlight text">aurora create &lt;new_job_key&gt; &lt;job_configuration&gt;
+<pre class="highlight text">aurora job create CLUSTER/ROLE/ENV/NEW_NAME &lt;job_configuration&gt;
 </pre></li>
 <li><p>Migrate all clients over to the new job key. Update all links and
 dashboards. Ensure that both job keys run identical versions of the
 code while in this state.</p></li>
 <li><p>After verifying that all clients have successfully moved over, kill
 the old job.</p>
-<pre class="highlight text">aurora kill &lt;old_job_key&gt;
+<pre class="highlight text">aurora job killall CLUSTER/ROLE/ENV/NAME
 </pre></li>
 <li><p>If you received a temporary quota increase, be sure to let the
 powers that be know you no longer need the additional capacity.</p></li>
@@ -352,124 +291,53 @@ powers that be know you no longer need t
 <h3 id="restarting-jobs">Restarting Jobs</h3>
 
 <p><code>restart</code> restarts all of a job key identified Job&rsquo;s shards:</p>
-<pre class="highlight text">aurora restart &lt;job_key&gt; &lt;configuration file&gt;
+<pre class="highlight text">aurora job restart CLUSTER/ROLE/ENV/NAME[/INSTANCES]
 </pre>
 <p>Restarts are controlled on the client side, so aborting
-the <code>restart</code> command halts the restart operation.</p>
-
-<p><code>restart</code> does a rolling restart. You almost always want to do this, but
-not if all shards of a service are misbehaving and are
-completely dysfunctional. To not do a rolling restart, use
-the <code>-shards</code> option described below.</p>
+the <code>job restart</code> command halts the restart operation.</p>
 
-<p><strong>Note</strong>: <code>restart</code> only applies its command line arguments and does not
+<p><strong>Note</strong>: <code>job restart</code> only applies its command line arguments and does not
 use or is affected by <code>update.config</code>. Restarting
 does <strong><em>not</em></strong> involve a configuration change. To update the
 configuration, use <code>update.config</code>.</p>
 
-<p>The <code>&lt;configuration file&gt;</code> argument for restart is optional. Use it only
+<p>The <code>--config</code> argument for restart is optional. Use it only
 if it contains hook definitions and activations that affect the
-<code>restart</code> command.</p>
-
-<p>In addition to the required job key argument, there are eight
-<code>restart</code> specific optional arguments:</p>
-
-<ul>
-<li><code>--updater_health_check_interval_seconds</code>: Defaults to <code>3</code>, the time
-interval between subsequent shard status checks.</li>
-<li><code>--shards=SHARDS</code>: Defaults to None, which restarts all shards.
-Otherwise, only the specified-by-id shards restart. They can be
-comma-separated <code>(0, 8, 9)</code>, a range <code>(3-5)</code> or a
-combination <code>(0, 3-5, 8, 9-11)</code>.</li>
-<li><code>--batch_size</code>: Defaults to <code>1</code>, the number of shards to be started
-in one iteration. So, for example, for value 3, it tries to restart
-the first three shards specified by <code>--shards</code> simultaneously, then
-the next three, and so on.</li>
-<li><code>--max_per_shard_failures=MAX_PER_SHARD_FAILURES</code>: Defaults to <code>0</code>,
-the maximum number of restarts per shard during restart. When
-exceeded, it increments the total failure count.</li>
-<li><code>--max_total_failures=MAX_TOTAL_FAILURES</code>: Defaults to <code>0</code>, the
-maximum total number of shard failures tolerated during restart.</li>
-<li><code>-o, --open_browser</code> Open a browser window to the scheduler UI Job
-page after a job changing operation happens. When <code>False</code>, the Job
-url prints on the console and the user has to copy/paste it
-manually. Defaults to <code>False</code>. Does not work when running in Vagrant.</li>
-<li><code>--restart_threshold</code>: Defaults to <code>60</code>, the maximum number of
-seconds before a shard must move into the <code>RUNNING</code> state before
-it&rsquo;s considered a failure.</li>
-<li><code>--watch_secs</code>: Defaults to <code>45</code>, the minimum number of seconds a
-shard must remain in <code>RUNNING</code> state before considered a success.</li>
-</ul>
+<code>job restart</code> command.</p>
 
 <h2 id="cron-jobs">Cron Jobs</h2>
 
+<p>You can manage cron jobs using the <code>aurora cron</code> command.  Please see
+<a href="/documentation/latest/cron-jobs/">cron-jobs.md</a> for more details.</p>
+
 <p>You will see various commands and options relating to cron jobs in
-<code>aurora -help</code> and similar. Ignore them, as they&rsquo;re not yet implemented.
-You might be able to use them without causing an error, but nothing happens
-if you do.</p>
+<code>aurora -h</code> and similar. Ignore them, as they&rsquo;re not yet implemented.</p>
 
 <h2 id="comparing-jobs">Comparing Jobs</h2>
-<pre class="highlight text">aurora diff &lt;job_key&gt; config
+<pre class="highlight text">aurora job diff CLUSTER/ROLE/ENV/NAME &lt;job configuration&gt;
 </pre>
 <p>Compares a job configuration against a running job. By default the diff
 is determined using <code>diff</code>, though you may choose an alternate
  diff program by specifying the <code>DIFF_VIEWER</code> environment variable.</p>
 
-<p>There are two named parameters:</p>
-
-<ul>
-<li><code>-E NAME=VALUE</code> Bind a Thermos mustache variable name to a
-value. Multiple flags may be used to specify multiple values.
-Defaults to <code>[]</code>.</li>
-<li><code>-j, --json</code> Read the configuration argument in JSON format.
-Defaults to <code>False</code>.</li>
-</ul>
-
 <h2 id="viewing/examining-jobs">Viewing/Examining Jobs</h2>
 
 <p>Above we discussed creating, killing, and updating Jobs. Here we discuss
 how to view and examine Jobs.</p>
 
 <h3 id="listing-jobs">Listing Jobs</h3>
-<pre class="highlight text">aurora list_jobs
-Usage: `aurora list_jobs cluster/role
+<pre class="highlight text">aurora config list &lt;job configuration&gt;
 </pre>
 <p>Lists all Jobs registered with the Aurora scheduler in the named cluster for the named role.</p>
 
-<p>It has two named parameters:</p>
-
-<ul>
-<li><code>--pretty</code>: Displays job information in prettyprinted format.
-Defaults to <code>False</code>.</li>
-<li><code>-c</code>, <code>--show-cron</code>: Shows cron schedule for jobs. Defaults to
-<code>False</code>. Do not use, as it&rsquo;s not yet implemented.</li>
-</ul>
-
 <h3 id="inspecting-a-job">Inspecting a Job</h3>
-<pre class="highlight text">aurora inspect &lt;job_key&gt; config
+<pre class="highlight text">aurora job inspect CLUSTER/ROLE/ENV/NAME &lt;job configuration&gt;
 </pre>
 <p><code>inspect</code> verifies that its specified job can be parsed from a
-configuration file, and displays the parsed configuration. It has four
-named parameters:</p>
-
-<ul>
-<li><code>--local</code>: Inspect the configuration that the  <code>spawn</code> command would
-create, defaulting to <code>False</code>.</li>
-<li><code>--raw</code>: Shows the raw configuration. Defaults to <code>False</code>.</li>
-<li><code>-j</code>, <code>--json</code>: If specified, configuration is read in JSON format.
-Defaults to <code>False</code>.</li>
-<li><code>-E NAME=VALUE</code>: Bind a Thermos Mustache variable name to a value.
-You can use multiple flags to specify multiple values. Defaults
-to <code>[]</code></li>
-</ul>
-
-<h3 id="versions">Versions</h3>
-<pre class="highlight text">aurora version
-</pre>
-<p>Lists client build information and what Aurora API version it supports.</p>
+configuration file, and displays the parsed configuration.</p>
 
 <h3 id="checking-your-quota">Checking Your Quota</h3>
-<pre class="highlight text">aurora get_quota --cluster=CLUSTER role
+<pre class="highlight text">aurora quota get CLUSTER/ROLE
 </pre>
 <p>Prints the production quota allocated to the role&rsquo;s value at the given
 cluster.</p>
@@ -492,7 +360,7 @@ Jobs are arranged by role, typically a s
 production jobs and user accounts for test or development jobs.</p>
 
 <h3 id="getting-job-status">Getting Job Status</h3>
-<pre class="highlight text">aurora status &lt;job_key&gt;
+<pre class="highlight text">aurora job status &lt;job_key&gt;
 </pre>
 <p>Returns the status of recent tasks associated with the
 <code>job_key</code> specified Job in its supplied cluster. Typically this includes
@@ -504,7 +372,7 @@ a mix of active tasks (running or assign
 <p>Use the Job&rsquo;s web UI scheduler URL or the <code>aurora status</code> command to find out on which
 machines individual tasks are scheduled. You can open the web UI via the
 <code>open</code> command line command if invoked from your machine:</p>
-<pre class="highlight text">aurora open [&lt;cluster&gt;[/&lt;role&gt;[/&lt;env&gt;/&lt;job_name&gt;]]]
+<pre class="highlight text">aurora job open [&lt;cluster&gt;[/&lt;role&gt;[/&lt;env&gt;/&lt;job_name&gt;]]]
 </pre>
 <p>If only the cluster is specified, it goes directly to that cluster&rsquo;s
 scheduler main page. If the role is specified, it goes to the top-level
@@ -512,26 +380,15 @@ role page. If the full job key is specif
 page where you can inspect individual tasks.</p>
 
 <h3 id="sshing-to-a-specific-task-machine">SSHing to a Specific Task Machine</h3>
-<pre class="highlight text">aurora ssh &lt;job_key&gt; &lt;shard number&gt;
+<pre class="highlight text">aurora task ssh &lt;job_key&gt; &lt;shard number&gt;
 </pre>
 <p>You can have the Aurora client ssh directly to the machine that has been
 assigned a particular Job/shard number. This may be useful for quickly
 diagnosing issues such as performance issues or abnormal behavior on a
 particular machine.</p>
 
-<p>It can take three named parameters:</p>
-
-<ul>
-<li><code>-e</code>, <code>--executor_sandbox</code>:  Run <code>ssh</code> in the executor sandbox
-instead of the  task sandbox. Defaults to <code>False</code>.</li>
-<li><code>--user=SSH_USER</code>: <code>ssh</code> as the given user instead of as the role in
-the <code>job_key</code> argument. Defaults to none.</li>
-<li><code>-L PORT:NAME</code>: Add tunnel from local port <code>PORT</code> to the remote
-named port  <code>NAME</code>. Defaults to <code>[]</code>.</li>
-</ul>
-
 <h3 id="templating-command-arguments">Templating Command Arguments</h3>
-<pre class="highlight text">aurora run [-e] [-t THREADS] &lt;job_key&gt; -- &lt;&lt;command-line&gt;&gt;
+<pre class="highlight text">aurora task run [-e] [-t THREADS] &lt;job_key&gt; -- &lt;&lt;command-line&gt;&gt;
 </pre>
 <p>Given a job specification, run the supplied command on all hosts and
 return the output. You may use the standard Mustache templating rules:</p>
@@ -547,7 +404,7 @@ assigned to this machine</li>
 
 <p>For example, the following type of pattern can be a powerful diagnostic
 tool:</p>
-<pre class="highlight text">aurora run -t5 cluster1/tyg/devel/seizure -- \
+<pre class="highlight text">aurora task run -t5 cluster1/tyg/devel/seizure -- \
   &#39;curl -s -m1 localhost:{{thermos.ports[http]}}/vars | grep uptime&#39;
 </pre>
 <p>By default, the command runs in the Task&rsquo;s sandbox. The <code>-e</code> option can

Modified: incubator/aurora/site/publish/documentation/latest/contributing/index.html
URL: http://svn.apache.org/viewvc/incubator/aurora/site/publish/documentation/latest/contributing/index.html?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/publish/documentation/latest/contributing/index.html (original)
+++ incubator/aurora/site/publish/documentation/latest/contributing/index.html Mon Jan 12 19:37:50 2015
@@ -44,6 +44,16 @@
 <p>First things first, you&rsquo;ll need the source! The Aurora source is available from Apache git:</p>
 <pre class="highlight text">git clone https://git-wip-us.apache.org/repos/asf/incubator-aurora
 </pre>
+<h2 id="read-the-style-guides">Read the Style Guides</h2>
+
+<p>Aurora&rsquo;s codebase is primarily Java and Python and conforms to the Twitter Commons styleguides for
+both languages.</p>
+
+<ul>
+<li><a href="https://github.com/twitter/commons/blob/master/src/java/com/twitter/common/styleguide.md">Java Style Guide</a></li>
+<li><a href="https://github.com/twitter/commons/blob/master/src/python/twitter/common/styleguide.md">Python Style Guide</a></li>
+</ul>
+
 <h2 id="find-something-to-do">Find Something to Do</h2>
 
 <p>There are issues in <a href="https://issues.apache.org/jira/browse/AURORA">Jira</a> with the

Modified: incubator/aurora/site/publish/documentation/latest/cron-jobs/index.html
URL: http://svn.apache.org/viewvc/incubator/aurora/site/publish/documentation/latest/cron-jobs/index.html?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/publish/documentation/latest/cron-jobs/index.html (original)
+++ incubator/aurora/site/publish/documentation/latest/cron-jobs/index.html Mon Jan 12 19:37:50 2015
@@ -123,24 +123,24 @@ set <code>max_task_failures</code> to <c
 
 <h2 id="interacting-with-cron-jobs-via-the-aurora-cli">Interacting with cron jobs via the Aurora CLI</h2>
 
-<p>Most interaction with cron jobs takes place using the <code>cron</code> subcommand. See <code>aurora2 help cron</code>
+<p>Most interaction with cron jobs takes place using the <code>cron</code> subcommand. See <code>aurora cron -h</code>
 for up-to-date usage instructions.</p>
 
 <h3 id="cron-schedule">cron schedule</h3>
 
 <p>Schedules a new cron job on the Aurora cluster for later runs or replaces the existing cron template
 with a new one. Only future runs will be affected, any existing active tasks are left intact.</p>
-<pre class="highlight text">$ aurora2 cron schedule devcluster/www-data/test/cron_hello_world /vagrant/examples/jobs/cron_hello_world.aurora
+<pre class="highlight text">$ aurora cron schedule devcluster/www-data/test/cron_hello_world /vagrant/examples/jobs/cron_hello_world.aurora
 </pre>
 <h3 id="cron-deschedule">cron deschedule</h3>
 
 <p>Deschedules a cron job, preventing future runs but allowing current runs to complete.</p>
-<pre class="highlight text">$ aurora2 cron deschedule devcluster/www-data/test/cron_hello_world
+<pre class="highlight text">$ aurora cron deschedule devcluster/www-data/test/cron_hello_world
 </pre>
 <h3 id="cron-start">cron start</h3>
 
 <p>Start a cron job immediately, outside of its normal cron schedule.</p>
-<pre class="highlight text">$ aurora2 cron start devcluster/www-data/test/cron_hello_world
+<pre class="highlight text">$ aurora cron start devcluster/www-data/test/cron_hello_world
 </pre>
 <h3 id="job-killall,-job-restart,-job-kill">job killall, job restart, job kill</h3>
 

Modified: incubator/aurora/site/publish/documentation/latest/developing-aurora-client/index.html
URL: http://svn.apache.org/viewvc/incubator/aurora/site/publish/documentation/latest/developing-aurora-client/index.html?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/publish/documentation/latest/developing-aurora-client/index.html (original)
+++ incubator/aurora/site/publish/documentation/latest/developing-aurora-client/index.html Mon Jan 12 19:37:50 2015
@@ -41,23 +41,9 @@
 <h5 class="page-header text-uppercase">Documentation</h5>
 <h1 id="getting-started">Getting Started</h1>
 
-<p>Aurora consists of four main pieces: the scheduler (which finds resources in the cluster that can be used to run a job), the executor (which uses the resources assigned by the scheduler to run a job), the command-line client, and the web-ui. For information about working on the scheduler or the webUI, see <a href="/documentation/latest/developing-aurora-scheduler/">Developing the Aurora Scheduler</a>.</p>
+<p>The client is written in Python, and uses the
+<a href="http://pantsbuild.github.io/python-readme.html">Pants</a> build tool.</p>
 
-<p>If you want to work on the command-line client, this is the place for you!</p>
-
-<p>The client is written in Python, and unlike the server side of things, we build the client using the Pants build tool, instead of Gradle. Pants is a tool that was built by twitter for handling builds of large collaborative systems. You can see a detailed explanation of
-pants <a href="http://pantsbuild.github.io/python-readme.html">here</a>.</p>
-
-<p>To build the client executable, run the following in a command-shell:</p>
-<pre class="highlight text">$ ./pants src/main/python/apache/aurora/client/cli:aurora2
-</pre>
-<p>This will produce a python executable <em>pex</em> file in <code>dist/aurora2.pex</code>. Pex files
-are fully self-contained executables: just copy the pex file into your path, and you&rsquo;ll be able to run it. For example, for a typical installation:</p>
-<pre class="highlight text">$ cp dist/aurora2.pex /usr/local/bin/aurora
-</pre>
-<p>To run all of the client tests:</p>
-<pre class="highlight text">$ ./pants src/test/python/apache/aurora/client/:all
-</pre>
 <h1 id="client-configuration">Client Configuration</h1>
 
 <p>The client uses a configuration file that specifies available clusters. More information about the
@@ -66,110 +52,27 @@ contents of this file can be found in th
 how the client locates this file can be found in the
 <a href="client-commands.md#cluster-configuration">Client Commands</a> documentation.</p>
 
-<h1 id="client-versions">Client Versions</h1>
-
-<p>There are currently two versions of the aurora client, imaginatively known as v1 and v2. All new development is done entirely in v2, but we continue to support and fix bugs in v1, until we get to the point where v2 is feature-complete and tested, and aurora users have had some time at adapt and switch their processes to use v2.</p>
-
-<p>Both versions are built on the same underlying API code.</p>
-
-<p>Client v1 was implemented using twitter.common.app. The command-line processing code for v1 can be found in <code>src/main/python/apache/aurora/client/commands</code> and
-<code>src/main/python/apache/aurora/client/bin</code>.</p>
-
-<p>Client v2 was implemented using its own noun/verb framework. The client v2 code can be found in <code>src/main/python/apache/aurora/client/cli</code>, and the noun/verb framework can be
-found in the <code>__init__.py</code> file in that directory.</p>
-
 <h1 id="building-and-testing-the-client">Building and Testing the Client</h1>
 
-<p>Building and testing the client code are both done using Pants. The relevant targets to know about are:</p>
+<p>Building and testing the client code are both done using Pants. The relevant targets to know about
+are:</p>
 
 <ul>
-<li>Build a client v2 executable: <code>./pants src/main/python/apache/aurora/client/cli:aurora2</code></li>
-<li>Test client v2 code: <code>./pants ./pants src/test/python/apache/aurora/client/cli:all</code></li>
-<li>Build a client v1 executable: <code>./pants src/main/python/apache/aurora/client/bin:aurora_client</code></li>
-<li>Test client v1 code: <code>./pants src/main/python/apache/aurora/client/commands:all</code></li>
-<li>Test all client code: <code>./pants src/main/python/apache/aurora/client:all</code></li>
+<li>Build a client executable: <code>./pants src/main/python/apache/aurora/client/cli:aurora</code></li>
+<li>Test client code: <code>./pants ./pants src/test/python/apache/aurora/client/cli:all</code></li>
 </ul>
 
-<h1 id="overview-of-the-client-architecture">Overview of the Client Architecture</h1>
-
-<p>The client is built on a stacked architecture:</p>
-
-<ol>
-<li><p>At the lowest level, we have a thrift RPC API interface
-to the aurora scheduler. The interface is declared in thrift, in the file
-<code>src/main/thrift/org/apache/aurora/gen/api.thrift</code>.</p>
-
-<ol>
-<li>On top of the primitive API, we have a client API. The client API
-takes the primitive operations provided by the scheduler, and uses them
-to implement client-side behaviors. For example, when you update a job,
-on the scheduler, that&rsquo;s done by a sequence of operations.  The sequence is implemented
-by the client API <code>update</code> method, which does the following using the thrift API:
-
-<ul>
-<li>fetching the state of task instances in the mesos cluster, and figuring out which need
-to be updated;</li>
-<li>For each task to be updated:
-
-<ul>
-<li>killing the old version;</li>
-<li>starting the new version;</li>
-<li>monitoring the new version to ensure that the update succeeded.</li>
-</ul></li>
-</ul></li>
-<li>On top of the API, we have the command-line client itself. The core client, at this level,
-consists of the interface to the command-line which the user will use to interact with aurora.
-The client v2 code is found in <code>src/python/apache/aurora/client/cli</code>. In the <code>cli</code> directory,
-the rough structure is as follows:
-
-<ul>
-<li><code>__init__.py</code> contains the noun/verb command-line processing framework used by client v2.</li>
-<li><code>jobs.py</code> contains the implementation of the core <code>job</code> noun, and all of its operations.</li>
-<li><code>bridge.py</code> contains the implementation of a component that allows us to ship a
-combined client that runs both v1 and v2 client commands during the transition period.</li>
-<li><code>client.py</code> contains the code that binds the client v2 nouns and verbs into an executable.</li>
-</ul></li>
-</ol></li>
-</ol>
-
 <h1 id="running/debugging-the-client">Running/Debugging the Client</h1>
 
-<p>For manually testing client changes against a cluster, we use vagrant. To start a virtual cluster,
-you need to install a working vagrant environment, and then run &ldquo;vagrant up&rdquo; for the root of
-the aurora workspace. This will create a vagrant host named &ldquo;devcluster&rdquo;, with a mesos master,
-a set of mesos slaves, and an aurora scheduler.</p>
-
-<p>To use the devcluster, you need to bring it up by running <code>vagrant up</code>, and then connect to the vagrant host using <code>vagrant ssh</code>. This will open a bash session on the virtual machine hosting the devcluster. In the home directory, there are two key paths to know about:</p>
-
-<ul>
-<li><code>~/aurora</code>: this is a copy of the git workspace in which you launched the vagrant cluster.
- To test client changes, you&rsquo;ll use this copy.</li>
-<li><code>/vagrant</code>: this is a mounted filesystem that&rsquo;s a direct image of your git workspace.
- This isn&rsquo;t a copy - it is your git workspace. Editing files on your host machine will
- be immediately visible here, because they are the same files.</li>
-</ul>
-
-<p>Whenever the scheduler is modified, to update your vagrant environment to use the new scheduler,
-you&rsquo;ll need to re-initialize your vagrant images. To do this, you need to run two commands:</p>
+<p>For manually testing client changes against a cluster, we use <a href="https://www.vagrantup.com/">Vagrant</a>.
+To start a virtual cluster, you need to install Vagrant, and then run <code>vagrant up</code> for the root of
+the aurora workspace. This will create a vagrant host named &ldquo;devcluster&rdquo;, with a mesos master, a set
+of mesos slaves, and an aurora scheduler.</p>
 
-<ul>
-<li><code>vagrant destroy</code>: this will delete the old devcluster image.</li>
-<li><code>vagrant up</code>: this creates a fresh devcluster image based on the current state of your workspace.</li>
-</ul>
-
-<p>You should try to minimize rebuilding vagrant images; it&rsquo;s not horribly slow, but it does take a while.</p>
-
-<p>To test client changes:</p>
-
-<ul>
-<li>Make a change in your local workspace, and commit it.</li>
-<li><code>vagrant ssh</code> into the devcluster.</li>
-<li><code>cd aurora</code></li>
-<li>Pull your changes into the vagrant copy: <code>git pull /vagrant *branchname*</code>.</li>
-<li>Build the modified client using pants.</li>
-<li>Run your command using <code>aurora2</code>. (You don&rsquo;t need to do any install; the aurora2 command
- is a symbolic link to the executable generated by pants.)</li>
-</ul>
+<p>If you have changed you would like to test in your local cluster, you&rsquo;ll rebuild the client:</p>
+<pre class="highlight text">vagrant ssh -c &#39;aurorabuild client&#39;
+</pre>
+<p>Once this completes, the <code>aurora</code> command will reflect your changes.</p>
 </div>
 
   		</div>

Modified: incubator/aurora/site/publish/documentation/latest/index.html
URL: http://svn.apache.org/viewvc/incubator/aurora/site/publish/documentation/latest/index.html?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/publish/documentation/latest/index.html (original)
+++ incubator/aurora/site/publish/documentation/latest/index.html Mon Jan 12 19:37:50 2015
@@ -39,8 +39,6 @@
   	  	<div class="container content">
           <div class="col-md-12">
 <h5 class="page-header text-uppercase">Documentation</h5>
-<h1 id="documentation">Documentation</h1>
-
 <h2 id="introduction">Introduction</h2>
 
 <p>Apache Aurora is a service scheduler that runs on top of Apache Mesos, enabling you to run long-running services that take advantage of Apache Mesos&#39; scalability, fault-tolerance, and resource isolation. This documentation has been organized into sections with three audiences in mind:</p>
@@ -62,7 +60,6 @@
 <li><a href="/documentation/latest/configuration-tutorial/">Configuration Tutorial</a></li>
 <li><a href="/documentation/latest/configuration-reference/">Aurora + Thermos Reference</a></li>
 <li><a href="/documentation/latest/client-commands/">Command Line Client</a></li>
-<li><a href="/documentation/latest/clientv2/">Aurora Client v2</a></li>
 <li><a href="/documentation/latest/cron-jobs/">Cron Jobs</a></li>
 </ul>
 

Modified: incubator/aurora/site/publish/documentation/latest/tutorial/index.html
URL: http://svn.apache.org/viewvc/incubator/aurora/site/publish/documentation/latest/tutorial/index.html?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/publish/documentation/latest/tutorial/index.html (original)
+++ incubator/aurora/site/publish/documentation/latest/tutorial/index.html Mon Jan 12 19:37:50 2015
@@ -293,7 +293,7 @@ and best practices for writing Aurora co
 the <a href="/documentation/latest/configuration-reference/">Aurora + Thermos Configuration Reference</a>.</li>
 <li>The <a href="/documentation/latest/user-guide/">Aurora User Guide</a> provides an overview of how Aurora, Mesos, and
 Thermos work &ldquo;under the hood&rdquo;.</li>
-<li>Explore the Aurora Client - use the <code>aurora help</code> subcommand, and read the
+<li>Explore the Aurora Client - use <code>aurora -h</code>, and read the
 <a href="/documentation/latest/client-commands/">Aurora Client Commands</a> document.</li>
 </ul>
 </div>

Modified: incubator/aurora/site/publish/documentation/latest/user-guide/index.html
URL: http://svn.apache.org/viewvc/incubator/aurora/site/publish/documentation/latest/user-guide/index.html?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/publish/documentation/latest/user-guide/index.html (original)
+++ incubator/aurora/site/publish/documentation/latest/user-guide/index.html Mon Jan 12 19:37:50 2015
@@ -419,18 +419,10 @@ about the Aurora Client.</p>
   jobs and user accounts for test or development jobs.</p>
 
 <ul>
-<li>The Aurora Client&rsquo;s command line interface</li>
+<li>The Aurora client</li>
 </ul>
 
-<p>Several Client commands have a <code>-o</code> option that automatically opens a window to
-  the specified Job&rsquo;s scheduler UI URL. And, as described above, the <code>open</code> command also takes
-  you there.</p>
-
-<p>For a complete list of Aurora Client commands, use <code>aurora help</code> and, for specific
-  command help, <code>aurora help [command]</code>. <strong>Note</strong>: <code>aurora help open</code>
-  returns <code>&quot;subcommand open not found&quot;</code> due to our reflection tricks not
-  working on words that are also builtin Python function names. Or see the
-  <a href="/documentation/latest/client-commands/">Aurora Client Commands</a> document.</p>
+<p>See <a href="/documentation/latest/client-commands/">client commands</a>.</p>
 </div>
 
   		</div>

Modified: incubator/aurora/site/source/documentation/latest.html.md
URL: http://svn.apache.org/viewvc/incubator/aurora/site/source/documentation/latest.html.md?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/source/documentation/latest.html.md (original)
+++ incubator/aurora/site/source/documentation/latest.html.md Mon Jan 12 19:37:50 2015
@@ -1,5 +1,3 @@
-# Documentation
-
 ## Introduction
 Apache Aurora is a service scheduler that runs on top of Apache Mesos, enabling you to run long-running services that take advantage of Apache Mesos' scalability, fault-tolerance, and resource isolation. This documentation has been organized into sections with three audiences in mind:
  
@@ -16,7 +14,6 @@ This documentation is a work in progress
  * [Configuration Tutorial](/documentation/latest/configuration-tutorial/)
  * [Aurora + Thermos Reference](/documentation/latest/configuration-reference/)
  * [Command Line Client](/documentation/latest/client-commands/)
- * [Aurora Client v2](/documentation/latest/clientv2/)
  * [Cron Jobs](/documentation/latest/cron-jobs/)
 
 ## Operators

Modified: incubator/aurora/site/source/documentation/latest/client-commands.md
URL: http://svn.apache.org/viewvc/incubator/aurora/site/source/documentation/latest/client-commands.md?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/source/documentation/latest/client-commands.md (original)
+++ incubator/aurora/site/source/documentation/latest/client-commands.md Mon Jan 12 19:37:50 2015
@@ -1,12 +1,6 @@
 Aurora Client Commands
 ======================
 
-The most up-to-date reference is in the client itself: use the
-`aurora help` subcommand (for example, `aurora help` or
-`aurora help create`) to find the latest information on parameters and
-functionality. Note that `aurora help open` does not work, due to underlying issues with
-reflection.
-
 - [Introduction](#introduction)
 - [Cluster Configuration](#cluster-configuration)
 - [Job Keys](#job-keys)
@@ -128,11 +122,11 @@ the machine executing Aurora commands.
 
 Hooks can be associated with these Aurora Client commands.
 
-  - `cancel_update`
-  - `create`
-  - `kill`
-  - `restart`
-  - `update`
+  - `job cancel-update`
+  - `job create`
+  - `job kill`
+  - `job restart`
+  - `job update`
 
 The process for writing and activating them is complex enough
 that we explain it in a devoted document, [Hooks for Aurora Client API](/documentation/latest/hooks/).
@@ -145,28 +139,14 @@ renaming, updating, and restarting a bas
 
 ### Creating and Running a Job
 
-    aurora create <job key> <configuration file>
+    aurora job create <job key> <configuration file>
 
 Creates and then runs a Job with the specified job key based on a `.aurora` configuration file.
 The configuration file may also contain and activate hook definitions.
 
-`create` can take four named parameters:
-
-- `-E NAME=VALUE` Bind a Thermos mustache variable name to a
-  value. Multiple flags specify multiple values. Defaults to `[]`.
-- ` -o, --open_browser` Open a browser window to the scheduler UI Job
-  page after a job changing operation happens. When `False`, the Job
-  URL prints on the console and the user has to copy/paste it
-  manually. Defaults to `False`. Does not work when running in Vagrant.
-- ` -j, --json` If specified, configuration argument is read as a
-  string in JSON format. Defaults to False.
-- ` --wait_until=STATE` Block the client until all the Tasks have
-  transitioned into the requested state. Possible values are: `PENDING`,
-  `RUNNING`, `FINISHED`. Default: `PENDING`
-
 ### Running a Command On a Running Job
 
-    aurora run <job_key> <cmd>
+    aurora task run CLUSTER/ROLE/ENV/NAME[/INSTANCES] <cmd>
 
 Runs a shell command on all machines currently hosting shards of a
 single Job.
@@ -175,75 +155,42 @@ single Job.
 commands; i.e. anything in the `{{mesos.*}}` and `{{thermos.*}}`
 namespaces.
 
-`run` can take three named parameters:
-
-- `-t NUM_THREADS`, `--threads=NUM_THREADS `The number of threads to
-  use, defaulting to `1`.
-- `--user=SSH_USER` ssh as this user instead of the given role value.
-  Defaults to None.
-- `-e, --executor_sandbox`  Run the command in the executor sandbox
-  instead of the Task sandbox. Defaults to False.
-
 ### Killing a Job
 
-    aurora kill <job key> <configuration file>
+    aurora job killall CLUSTER/ROLE/ENV/NAME
 
 Kills all Tasks associated with the specified Job, blocking until all
-are terminated. Defaults to killing all shards in the Job.
+are terminated. Defaults to killing all instances in the Job.
 
 The `<configuration file>` argument for `kill` is optional. Use it only
 if it contains hook definitions and activations that affect the
 kill command.
 
-`kill` can take two named parameters:
-
-- `-o, --open_browser` Open a browser window to the scheduler UI Job
-  page after a job changing operation happens. When `False`, the Job
-  URL prints on the console and the user has to copy/paste it
-  manually. Defaults to `False`. Does not work when running in Vagrant.
-- `--shards=SHARDS` A list of shard ids to act on. Can either be a
-  comma-separated list (e.g. 0,1,2) or a range (e.g. 0-2) or  any
-  combination of the two (e.g. 0-2,5,7-9). Defaults to acting on all
-  shards.
-
 ### Updating a Job
 
-    aurora update [--shards=ids] <job key> <configuration file>
-    aurora cancel_update <job key> <configuration file>
+    aurora job update CLUSTER/ROLE/ENV/NAME[/INSTANCES] <configuration file>
+    aurora job cancel-update CLUSTER/ROLE/ENV/NAME
 
 Given a running job, does a rolling update to reflect a new
 configuration version. Only updates Tasks in the Job with a changed
-configuration. You can further restrict the operated on Tasks by
-using `--shards` and specifying a comma-separated list of job shard ids.
+configuration. You can further restrict the operated on Tasks by specifying
+specific instances that should be updated.
 
-You may want to run `aurora diff` beforehand to validate which Tasks
+You may want to run `aurora job diff` beforehand to validate which Tasks
 have different configurations.
 
 Updating jobs are locked to be sure the update finishes without
 disruption. If the update abnormally terminates, the lock may stay
 around and cause failure of subsequent update attempts.
- `aurora cancel_update `unlocks the Job specified by
-its `job_key` argument. Be sure you don't issue `cancel_update` when
+ `aurora job cancel-update `unlocks the Job specified by
+its `job_key` argument. Be sure you don't issue `job cancel-update` when
 another user is working with the specified Job.
 
-The `<configuration file>` argument for `cancel_update` is optional. Use
+The `<configuration file>` argument for `job cancel-update` is optional. Use
 it only if it contains hook definitions and activations that affect the
 `cancel_update` command. The `<configuration file>` argument for
 `update` is required, but in addition to a new configuration it can be
-used to define and activate hooks for `update`.
-
-`update` can take four named parameters:
-
-- `--shards=SHARDS` A list of shard ids to update. Can either be a
-  comma-separated list (e.g. 0,1,2) or a range (e.g. 0-2) or  any
-  combination of the two (e.g. 0-2,5,7-9). If not  set, all shards are
-  acted on. Defaults to None.
-- `-E NAME=VALUE` Binds a Thermos mustache variable name to a value.
-  Use multiple flags to specify multiple values. Defaults to `[]`.
-- `-j, --json` If specified, configuration is read in JSON format.
-  Defaults to `False`.
-- `--updater_health_check_interval_seconds=HEALTH_CHECK_INTERVAL_SECONDS`
-  Time interval between subsequent shard status checks. Defaults to `3`.
+used to define and activate hooks for `job update`.
 
 #### Asynchronous job updates (beta)
 
@@ -253,12 +200,12 @@ update progress and job update history i
 
 There are several sub-commands to manage job updates:
 
-    aurora2 beta-update start <job key> <configuration file
-    aurora2 beta-update status <job key>
-    aurora2 beta-update pause <job key>
-    aurora2 beta-update resume <job key>
-    aurora2 beta-update abort <job key>
-    aurora2 beta-update list <cluster>
+    aurora beta-update start <job key> <configuration file>
+    aurora beta-update status <job key>
+    aurora beta-update pause <job key>
+    aurora beta-update resume <job key>
+    aurora beta-update abort <job key>
+    aurora beta-update list <cluster>
 
 When you `start` a job update, the command will return once it has sent the
 instructions to the scheduler.  At that point, you may view detailed
@@ -287,12 +234,12 @@ to renaming suitable for production serv
 2.  Check that only these naming components have changed
     with `aurora diff`.
 
-        aurora diff <job_key> <job_configuration>
+        aurora job diff CLUSTER/ROLE/ENV/NAME <job_configuration>
 
 3.  Create the (identical) job at the new key. You may need to request a
     temporary quota increase.
 
-        aurora create <new_job_key> <job_configuration>
+        aurora job create CLUSTER/ROLE/ENV/NEW_NAME <job_configuration>
 
 4.  Migrate all clients over to the new job key. Update all links and
     dashboards. Ensure that both job keys run identical versions of the
@@ -300,7 +247,7 @@ to renaming suitable for production serv
 5.  After verifying that all clients have successfully moved over, kill
     the old job.
 
-        aurora kill <old_job_key>
+        aurora job killall CLUSTER/ROLE/ENV/NAME
 
 6.  If you received a temporary quota increase, be sure to let the
     powers that be know you no longer need the additional capacity.
@@ -309,78 +256,38 @@ to renaming suitable for production serv
 
 `restart` restarts all of a job key identified Job's shards:
 
-    aurora restart <job_key> <configuration file>
+    aurora job restart CLUSTER/ROLE/ENV/NAME[/INSTANCES]
 
 Restarts are controlled on the client side, so aborting
-the `restart` command halts the restart operation.
+the `job restart` command halts the restart operation.
 
-`restart` does a rolling restart. You almost always want to do this, but
-not if all shards of a service are misbehaving and are
-completely dysfunctional. To not do a rolling restart, use
-the `-shards` option described below.
-
-**Note**: `restart` only applies its command line arguments and does not
+**Note**: `job restart` only applies its command line arguments and does not
 use or is affected by `update.config`. Restarting
 does ***not*** involve a configuration change. To update the
 configuration, use `update.config`.
 
-The `<configuration file>` argument for restart is optional. Use it only
+The `--config` argument for restart is optional. Use it only
 if it contains hook definitions and activations that affect the
-`restart` command.
-
-In addition to the required job key argument, there are eight
-`restart` specific optional arguments:
-
-- `--updater_health_check_interval_seconds`: Defaults to `3`, the time
-  interval between subsequent shard status checks.
-- `--shards=SHARDS`: Defaults to None, which restarts all shards.
-  Otherwise, only the specified-by-id shards restart. They can be
-  comma-separated `(0, 8, 9)`, a range `(3-5)` or a
-  combination `(0, 3-5, 8, 9-11)`.
-- `--batch_size`: Defaults to `1`, the number of shards to be started
-  in one iteration. So, for example, for value 3, it tries to restart
-  the first three shards specified by `--shards` simultaneously, then
-  the next three, and so on.
-- `--max_per_shard_failures=MAX_PER_SHARD_FAILURES`: Defaults to `0`,
-  the maximum number of restarts per shard during restart. When
-  exceeded, it increments the total failure count.
-- `--max_total_failures=MAX_TOTAL_FAILURES`: Defaults to `0`, the
-  maximum total number of shard failures tolerated during restart.
-- `-o, --open_browser` Open a browser window to the scheduler UI Job
-  page after a job changing operation happens. When `False`, the Job
-  url prints on the console and the user has to copy/paste it
-  manually. Defaults to `False`. Does not work when running in Vagrant.
-- `--restart_threshold`: Defaults to `60`, the maximum number of
-  seconds before a shard must move into the `RUNNING` state before
-  it's considered a failure.
-- `--watch_secs`: Defaults to `45`, the minimum number of seconds a
-  shard must remain in `RUNNING` state before considered a success.
+`job restart` command.
 
 Cron Jobs
 ---------
 
+You can manage cron jobs using the `aurora cron` command.  Please see
+[cron-jobs.md](/documentation/latest/cron-jobs/) for more details.
+
 You will see various commands and options relating to cron jobs in
-`aurora -help` and similar. Ignore them, as they're not yet implemented.
-You might be able to use them without causing an error, but nothing happens
-if you do.
+`aurora -h` and similar. Ignore them, as they're not yet implemented.
 
 Comparing Jobs
 --------------
 
-    aurora diff <job_key> config
+    aurora job diff CLUSTER/ROLE/ENV/NAME <job configuration>
 
 Compares a job configuration against a running job. By default the diff
 is determined using `diff`, though you may choose an alternate
  diff program by specifying the `DIFF_VIEWER` environment variable.
 
-There are two named parameters:
-
-- `-E NAME=VALUE` Bind a Thermos mustache variable name to a
-  value. Multiple flags may be used to specify multiple values.
-  Defaults to `[]`.
-- `-j, --json` Read the configuration argument in JSON format.
-  Defaults to `False`.
-
 Viewing/Examining Jobs
 ----------------------
 
@@ -389,44 +296,20 @@ how to view and examine Jobs.
 
 ### Listing Jobs
 
-    aurora list_jobs
-    Usage: `aurora list_jobs cluster/role
+    aurora config list <job configuration>
 
 Lists all Jobs registered with the Aurora scheduler in the named cluster for the named role.
 
-It has two named parameters:
-
-- `--pretty`: Displays job information in prettyprinted format.
-  Defaults to `False`.
-- `-c`, `--show-cron`: Shows cron schedule for jobs. Defaults to
-  `False`. Do not use, as it's not yet implemented.
-
 ### Inspecting a Job
 
-    aurora inspect <job_key> config
+    aurora job inspect CLUSTER/ROLE/ENV/NAME <job configuration>
 
 `inspect` verifies that its specified job can be parsed from a
-configuration file, and displays the parsed configuration. It has four
-named parameters:
-
-- `--local`: Inspect the configuration that the  `spawn` command would
-  create, defaulting to `False`.
-- `--raw`: Shows the raw configuration. Defaults to `False`.
-- `-j`, `--json`: If specified, configuration is read in JSON format.
-  Defaults to `False`.
-- `-E NAME=VALUE`: Bind a Thermos Mustache variable name to a value.
-  You can use multiple flags to specify multiple values. Defaults
-  to `[]`
-
-### Versions
-
-    aurora version
-
-Lists client build information and what Aurora API version it supports.
+configuration file, and displays the parsed configuration.
 
 ### Checking Your Quota
 
-    aurora get_quota --cluster=CLUSTER role
+    aurora quota get CLUSTER/ROLE
 
   Prints the production quota allocated to the role's value at the given
 cluster.
@@ -451,7 +334,7 @@ production jobs and user accounts for te
 
 ### Getting Job Status
 
-    aurora status <job_key>
+    aurora job status <job_key>
 
 Returns the status of recent tasks associated with the
 `job_key` specified Job in its supplied cluster. Typically this includes
@@ -464,7 +347,7 @@ Use the Job's web UI scheduler URL or th
 machines individual tasks are scheduled. You can open the web UI via the
 `open` command line command if invoked from your machine:
 
-    aurora open [<cluster>[/<role>[/<env>/<job_name>]]]
+    aurora job open [<cluster>[/<role>[/<env>/<job_name>]]]
 
 If only the cluster is specified, it goes directly to that cluster's
 scheduler main page. If the role is specified, it goes to the top-level
@@ -473,25 +356,16 @@ page where you can inspect individual ta
 
 ### SSHing to a Specific Task Machine
 
-    aurora ssh <job_key> <shard number>
+    aurora task ssh <job_key> <shard number>
 
 You can have the Aurora client ssh directly to the machine that has been
 assigned a particular Job/shard number. This may be useful for quickly
 diagnosing issues such as performance issues or abnormal behavior on a
 particular machine.
 
-It can take three named parameters:
-
-- `-e`, `--executor_sandbox`:  Run `ssh` in the executor sandbox
-  instead of the  task sandbox. Defaults to `False`.
-- `--user=SSH_USER`: `ssh` as the given user instead of as the role in
-  the `job_key` argument. Defaults to none.
-- `-L PORT:NAME`: Add tunnel from local port `PORT` to the remote
-  named port  `NAME`. Defaults to `[]`.
-
 ### Templating Command Arguments
 
-    aurora run [-e] [-t THREADS] <job_key> -- <<command-line>>
+    aurora task run [-e] [-t THREADS] <job_key> -- <<command-line>>
 
 Given a job specification, run the supplied command on all hosts and
 return the output. You may use the standard Mustache templating rules:
@@ -506,7 +380,7 @@ return the output. You may use the stand
 For example, the following type of pattern can be a powerful diagnostic
 tool:
 
-    aurora run -t5 cluster1/tyg/devel/seizure -- \
+    aurora task run -t5 cluster1/tyg/devel/seizure -- \
       'curl -s -m1 localhost:{{thermos.ports[http]}}/vars | grep uptime'
 
 By default, the command runs in the Task's sandbox. The `-e` option can

Modified: incubator/aurora/site/source/documentation/latest/contributing.md
URL: http://svn.apache.org/viewvc/incubator/aurora/site/source/documentation/latest/contributing.md?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/source/documentation/latest/contributing.md (original)
+++ incubator/aurora/site/source/documentation/latest/contributing.md Mon Jan 12 19:37:50 2015
@@ -4,6 +4,14 @@ First things first, you'll need the sour
 
     git clone https://git-wip-us.apache.org/repos/asf/incubator-aurora
 
+Read the Style Guides
+---------------------
+Aurora's codebase is primarily Java and Python and conforms to the Twitter Commons styleguides for
+both languages.
+
+- [Java Style Guide](https://github.com/twitter/commons/blob/master/src/java/com/twitter/common/styleguide.md)
+- [Python Style Guide](https://github.com/twitter/commons/blob/master/src/python/twitter/common/styleguide.md)
+
 Find Something to Do
 --------------------
 There are issues in [Jira](https://issues.apache.org/jira/browse/AURORA) with the

Modified: incubator/aurora/site/source/documentation/latest/cron-jobs.md
URL: http://svn.apache.org/viewvc/incubator/aurora/site/source/documentation/latest/cron-jobs.md?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/source/documentation/latest/cron-jobs.md (original)
+++ incubator/aurora/site/source/documentation/latest/cron-jobs.md Mon Jan 12 19:37:50 2015
@@ -72,24 +72,24 @@ set `max_task_failures` to `-1`.
 
 ## Interacting with cron jobs via the Aurora CLI
 
-Most interaction with cron jobs takes place using the `cron` subcommand. See `aurora2 help cron`
+Most interaction with cron jobs takes place using the `cron` subcommand. See `aurora cron -h`
 for up-to-date usage instructions.
 
 ### cron schedule
 Schedules a new cron job on the Aurora cluster for later runs or replaces the existing cron template
 with a new one. Only future runs will be affected, any existing active tasks are left intact.
 
-    $ aurora2 cron schedule devcluster/www-data/test/cron_hello_world /vagrant/examples/jobs/cron_hello_world.aurora
+    $ aurora cron schedule devcluster/www-data/test/cron_hello_world /vagrant/examples/jobs/cron_hello_world.aurora
 
 ### cron deschedule
 Deschedules a cron job, preventing future runs but allowing current runs to complete.
 
-    $ aurora2 cron deschedule devcluster/www-data/test/cron_hello_world
+    $ aurora cron deschedule devcluster/www-data/test/cron_hello_world
 
 ### cron start
 Start a cron job immediately, outside of its normal cron schedule.
 
-    $ aurora2 cron start devcluster/www-data/test/cron_hello_world
+    $ aurora cron start devcluster/www-data/test/cron_hello_world
 
 ### job killall, job restart, job kill
 Cron jobs create instances running on the cluster that you can interact with like normal Aurora

Modified: incubator/aurora/site/source/documentation/latest/developing-aurora-client.md
URL: http://svn.apache.org/viewvc/incubator/aurora/site/source/documentation/latest/developing-aurora-client.md?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/source/documentation/latest/developing-aurora-client.md (original)
+++ incubator/aurora/site/source/documentation/latest/developing-aurora-client.md Mon Jan 12 19:37:50 2015
@@ -1,26 +1,8 @@
 Getting Started
 ===============
 
-Aurora consists of four main pieces: the scheduler (which finds resources in the cluster that can be used to run a job), the executor (which uses the resources assigned by the scheduler to run a job), the command-line client, and the web-ui. For information about working on the scheduler or the webUI, see [Developing the Aurora Scheduler](/documentation/latest/developing-aurora-scheduler/).
-
-If you want to work on the command-line client, this is the place for you!
-
-The client is written in Python, and unlike the server side of things, we build the client using the Pants build tool, instead of Gradle. Pants is a tool that was built by twitter for handling builds of large collaborative systems. You can see a detailed explanation of
-pants [here](http://pantsbuild.github.io/python-readme.html).
-
-To build the client executable, run the following in a command-shell:
-
-    $ ./pants src/main/python/apache/aurora/client/cli:aurora2
-
-This will produce a python executable _pex_ file in `dist/aurora2.pex`. Pex files
-are fully self-contained executables: just copy the pex file into your path, and you'll be able to run it. For example, for a typical installation:
-
-    $ cp dist/aurora2.pex /usr/local/bin/aurora
-
-To run all of the client tests:
-
-    $ ./pants src/test/python/apache/aurora/client/:all
-
+The client is written in Python, and uses the
+[Pants](http://pantsbuild.github.io/python-readme.html) build tool.
 
 Client Configuration
 ====================
@@ -31,92 +13,25 @@ contents of this file can be found in th
 how the client locates this file can be found in the
 [Client Commands](client-commands.md#cluster-configuration) documentation.
 
-Client Versions
-===============
-
-There are currently two versions of the aurora client, imaginatively known as v1 and v2. All new development is done entirely in v2, but we continue to support and fix bugs in v1, until we get to the point where v2 is feature-complete and tested, and aurora users have had some time at adapt and switch their processes to use v2.
-
-Both versions are built on the same underlying API code.
-
-Client v1 was implemented using twitter.common.app. The command-line processing code for v1 can be found in `src/main/python/apache/aurora/client/commands` and
-`src/main/python/apache/aurora/client/bin`.
-
-Client v2 was implemented using its own noun/verb framework. The client v2 code can be found in `src/main/python/apache/aurora/client/cli`, and the noun/verb framework can be
-found in the `__init__.py` file in that directory.
-
-
 Building and Testing the Client
 ===============================
 
-Building and testing the client code are both done using Pants. The relevant targets to know about are:
+Building and testing the client code are both done using Pants. The relevant targets to know about
+are:
 
-   * Build a client v2 executable: `./pants src/main/python/apache/aurora/client/cli:aurora2`
-   * Test client v2 code: `./pants ./pants src/test/python/apache/aurora/client/cli:all`
-   * Build a client v1 executable: `./pants src/main/python/apache/aurora/client/bin:aurora_client`
-   * Test client v1 code: `./pants src/main/python/apache/aurora/client/commands:all`
-   * Test all client code: `./pants src/main/python/apache/aurora/client:all`
-
-
-Overview of the Client Architecture
-===================================
-
-The client is built on a stacked architecture:
-
-   1. At the lowest level, we have a thrift RPC API interface
-    to the aurora scheduler. The interface is declared in thrift, in the file
-    `src/main/thrift/org/apache/aurora/gen/api.thrift`.
-
-  2. On top of the primitive API, we have a client API. The client API
-    takes the primitive operations provided by the scheduler, and uses them
-    to implement client-side behaviors. For example, when you update a job,
-    on the scheduler, that's done by a sequence of operations.  The sequence is implemented
-    by the client API `update` method, which does the following using the thrift API:
-     * fetching the state of task instances in the mesos cluster, and figuring out which need
-       to be updated;
-     * For each task to be updated:
-         - killing the old version;
-         - starting the new version;
-         - monitoring the new version to ensure that the update succeeded.
-  3. On top of the API, we have the command-line client itself. The core client, at this level,
-    consists of the interface to the command-line which the user will use to interact with aurora.
-    The client v2 code is found in `src/python/apache/aurora/client/cli`. In the `cli` directory,
-    the rough structure is as follows:
-       * `__init__.py` contains the noun/verb command-line processing framework used by client v2.
-       * `jobs.py` contains the implementation of the core `job` noun, and all of its operations.
-       * `bridge.py` contains the implementation of a component that allows us to ship a
-         combined client that runs both v1 and v2 client commands during the transition period.
-       * `client.py` contains the code that binds the client v2 nouns and verbs into an executable.
+   * Build a client executable: `./pants src/main/python/apache/aurora/client/cli:aurora`
+   * Test client code: `./pants ./pants src/test/python/apache/aurora/client/cli:all`
 
 Running/Debugging the Client
 ============================
 
-For manually testing client changes against a cluster, we use vagrant. To start a virtual cluster,
-you need to install a working vagrant environment, and then run "vagrant up" for the root of
-the aurora workspace. This will create a vagrant host named "devcluster", with a mesos master,
-a set of mesos slaves, and an aurora scheduler.
-
-To use the devcluster, you need to bring it up by running `vagrant up`, and then connect to the vagrant host using `vagrant ssh`. This will open a bash session on the virtual machine hosting the devcluster. In the home directory, there are two key paths to know about:
-
-   * `~/aurora`: this is a copy of the git workspace in which you launched the vagrant cluster.
-     To test client changes, you'll use this copy.
-   * `/vagrant`: this is a mounted filesystem that's a direct image of your git workspace.
-     This isn't a copy - it is your git workspace. Editing files on your host machine will
-     be immediately visible here, because they are the same files.
-
-Whenever the scheduler is modified, to update your vagrant environment to use the new scheduler,
-you'll need to re-initialize your vagrant images. To do this, you need to run two commands:
-
-   * `vagrant destroy`: this will delete the old devcluster image.
-   * `vagrant up`: this creates a fresh devcluster image based on the current state of your workspace.
-
-You should try to minimize rebuilding vagrant images; it's not horribly slow, but it does take a while.
-
-To test client changes:
-
-   * Make a change in your local workspace, and commit it.
-   * `vagrant ssh` into the devcluster.
-   * `cd aurora`
-   * Pull your changes into the vagrant copy: `git pull /vagrant *branchname*`.
-   * Build the modified client using pants.
-   * Run your command using `aurora2`. (You don't need to do any install; the aurora2 command
-     is a symbolic link to the executable generated by pants.)
+For manually testing client changes against a cluster, we use [Vagrant](https://www.vagrantup.com/).
+To start a virtual cluster, you need to install Vagrant, and then run `vagrant up` for the root of
+the aurora workspace. This will create a vagrant host named "devcluster", with a mesos master, a set
+of mesos slaves, and an aurora scheduler.
+
+If you have changed you would like to test in your local cluster, you'll rebuild the client:
+
+    vagrant ssh -c 'aurorabuild client'
+
+Once this completes, the `aurora` command will reflect your changes.

Modified: incubator/aurora/site/source/documentation/latest/tutorial.md
URL: http://svn.apache.org/viewvc/incubator/aurora/site/source/documentation/latest/tutorial.md?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/source/documentation/latest/tutorial.md (original)
+++ incubator/aurora/site/source/documentation/latest/tutorial.md Mon Jan 12 19:37:50 2015
@@ -261,5 +261,5 @@ Now that you've finished this Tutorial,
   the [Aurora + Thermos Configuration Reference](/documentation/latest/configuration-reference/).
 - The [Aurora User Guide](/documentation/latest/user-guide/) provides an overview of how Aurora, Mesos, and
   Thermos work "under the hood".
-- Explore the Aurora Client - use the `aurora help` subcommand, and read the
+- Explore the Aurora Client - use `aurora -h`, and read the
   [Aurora Client Commands](/documentation/latest/client-commands/) document.

Modified: incubator/aurora/site/source/documentation/latest/user-guide.md
URL: http://svn.apache.org/viewvc/incubator/aurora/site/source/documentation/latest/user-guide.md?rev=1651176&r1=1651175&r2=1651176&view=diff
==============================================================================
--- incubator/aurora/site/source/documentation/latest/user-guide.md (original)
+++ incubator/aurora/site/source/documentation/latest/user-guide.md Mon Jan 12 19:37:50 2015
@@ -350,14 +350,6 @@ You interact with Aurora jobs either via
   jobs, and finished jobs. Jobs are arranged by role, typically a service account for production
   jobs and user accounts for test or development jobs.
 
-- The Aurora Client's command line interface
+- The Aurora client
 
-  Several Client commands have a `-o` option that automatically opens a window to
-  the specified Job's scheduler UI URL. And, as described above, the `open` command also takes
-  you there.
-
-  For a complete list of Aurora Client commands, use `aurora help` and, for specific
-  command help, `aurora help [command]`. **Note**: `aurora help open`
-  returns `"subcommand open not found"` due to our reflection tricks not
-  working on words that are also builtin Python function names. Or see the
-  [Aurora Client Commands](/documentation/latest/client-commands/) document.
+  See [client commands](/documentation/latest/client-commands/).



Mime
View raw message