aurora-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject incubator-aurora git commit: Scrub docs of remaining references to aurora2 and aurora help.
Date Fri, 09 Jan 2015 21:17:19 GMT
Repository: incubator-aurora
Updated Branches:
  refs/heads/master 8c2786437 -> 1f907da2c

Scrub docs of remaining references to aurora2 and aurora help.

Reviewed at


Branch: refs/heads/master
Commit: 1f907da2c0d7a572d7e9091f5a303318b0692310
Parents: 8c27864
Author: Bill Farner <>
Authored: Fri Jan 9 13:16:41 2015 -0800
Committer: Bill Farner <>
Committed: Fri Jan 9 13:16:41 2015 -0800

 docs/                             |  8 +-
 docs/              | 87 +++-------------------
 docs/                              |  2 +-
 docs/                            | 12 +--
 src/test/sh/org/apache/aurora/e2e/ |  4 +-
 5 files changed, 20 insertions(+), 93 deletions(-)
diff --git a/docs/ b/docs/
index c3e8eed..41770fd 100644
--- a/docs/
+++ b/docs/
@@ -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
+Most interaction with cron jobs takes place using the `cron` subcommand. See `aurora cron
 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
 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
diff --git a/docs/ b/docs/
index 83b843e..a7253d2 100644
--- a/docs/
+++ b/docs/
@@ -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](
-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](
-To build the client executable, run the following in a command-shell:
-    $ ./pants src/main/python/apache/aurora/client/cli:aurora
-This will produce a python executable _pex_ file in `dist/aurora.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/aurora.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]( build tool.
 Client Configuration
@@ -34,69 +16,22 @@ how the client locates this file can be found in the
 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
    * 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`
-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
-       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
-    consists of the interface to the command-line which the user will use to interact with
-    The client code is found in `src/python/apache/aurora/client/cli`. In the `cli` directory,
-    the rough structure is as follows:
-       * `` contains the noun/verb command-line processing framework used by client.
-       * `` contains the implementation of the core `job` noun, and all of its operations.
-       * `` contains the code that binds the client nouns and verbs into an executable.
 Running/Debugging the Client
-For manually testing client changes against a cluster, we use vagrant. To start a virtual
-you need to install a working vagrant environment, and then run "vagrant up" for the root
-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
+For manually testing client changes against a cluster, we use [Vagrant](
+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.
-You should try to minimize rebuilding vagrant images; it's not horribly slow, but it does
take a while.
+If you have changed you would like to test in your local cluster, you'll rebuild the client:
-To test client changes:
+    vagrant ssh -c 'aurorabuild client'
-   * 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.)
+Once this completes, the `aurora` command will reflect your changes.
diff --git a/docs/ b/docs/
index e46addd..7ea36e4 100644
--- a/docs/
+++ b/docs/
@@ -261,5 +261,5 @@ Now that you've finished this Tutorial, you should read or do the following:
   the [Aurora + Thermos Configuration Reference](
 - The [Aurora 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]( document.
diff --git a/docs/ b/docs/
index 877f5b7..154b470 100644
--- a/docs/
+++ b/docs/
@@ -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
-  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]( document.
+  See [client commands](
diff --git a/src/test/sh/org/apache/aurora/e2e/ b/src/test/sh/org/apache/aurora/e2e/
index c3822ad..ab91b95 100755
--- a/src/test/sh/org/apache/aurora/e2e/
+++ b/src/test/sh/org/apache/aurora/e2e/
@@ -13,14 +13,14 @@
 # limitations under the License.
-# Test aurora run/aurora2 task run. This script is meant to be run within an ssh-agent to
+# Test aurora run/aurora task run. This script is meant to be run within an ssh-agent to
 # avoid polluting the global ssh-agent w/ the vagrant private key.
 set -u -e -x
-aurora_command=${3:-"aurora2 task run"}
+aurora_command=${3:-"aurora task run"}
 ssh-add $HOME/.vagrant.d/insecure_private_key
 vagrant ssh -c "$aurora_command $jobkey 'pwd'" -- -A -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null

View raw message