Using the "--cluster" option, the cloud client can direct the workspace
service to launch any number (and any type) of workspaces simultaneously.
Something called the context broker will work behind the scenes to
make sure each node has the information they need to play their various
roles.

You can bring up the exact cluster you need whenever necessary. It's portable
across clouds, too. If you need to make some updates you can re-launch from
a new template image (that you already tested at small scale). You can
also customize files on a per launch basis to make the cluster have different
policies or behaviors. You can even direct the same image file to take on
different roles depending on what the context broker tells it.

No private keys need to live on the images in your cluster before
they are booted. This means you can freely collaborate on useful setups and
distribute them openly over the internet to end users.

RFT service at "https://HEADNODE_HOSTNAME:8443/wsrf/services/ReliableFileTransferFactoryService"

Some notes:

Any user account (including root) can freely SSH across the cluster to corresponding account

The "/home" directory is mounted from headnode to each compute over NFS

You should map your DN to the 'jobrun' account (like the sample value in base-cluster.xml)

To make your image(s) auto-configure your own software choices, see
How do I make images of my own do
this?. While this will take more than "one click" to set up, our
alpha users have had successes in short order. You can run and
auto-configure pretty much any type of software/application that will run
on a normal cluster.

Some information is printed (including the assigned IP addresses), just
like with single launches. We quickly move to this output:

Launching cluster-001... done.
Waiting for launch updates.

This is the first of two waiting periods, this is when the images files make
their way to the hypervisors and it will take a few minutes. The next
waiting period is much shorter.

While you're waiting, make a mental note of the handle. This will look
something like "cluster-001". This is just like "vm-001" for non-cluster
launches, you can use it to manage things, for example terminate
("./bin/cloud-client.sh --terminate --handle cluster-001")

- cluster-001: all members are Running
- wrote reports to '/tmp/cloud-client/history/cluster-001/reports-vm'

Everything is now "Running" which really means the VMs are all at least
booting. If there was a problem, an error notice would
print to the screen and the "reports-vm" directory that is listed here would
have all the details on any errors.

Information is archived in that directory for successes, too, but you
typically only need the hostname to log into or submit jobs to. That
hostname is printed to the screen and also always available by looking at
your history/cluster-001/run-log.txt file.

Contextualization reports are available at the listed reports directory but
like the launch reports, you don't really need to pay attention unless there
was an error. If there is an error, the error reports are written to the
reports directory and the cluster is backed out. These error reports
include all logs of each context agent (all output leading up to the
problem, non-errors included too).

That final SSH message means that the client retrieved the SSH
public keys from the context broker -- they are installed already to your
local known_hosts file. Which mean you can take an address and log in as
root:

$
ssh root@hostname1.cloudurl.edu

... and you do not get "The authenticity of host 'xyz (1.2.3.4)' can't be
established" messages anymore.

This relieves you of that pesky 'y' keystroke to accept the key -- and no
more "WARNING KEY HAS CHANGED" messages when you've been given an IP that's
been seen before. But this importantly means the gap is closed on
possible man-in-the-middle attacks. Through secure channels end to end,
the client is able to know the public key that each instance generated at
boot.

You can turn off this
auto-configuration of your known_hosts file by removing the "ssh.hostsfile"
configuration from the conf/cloud.properties file.
Also, to support large virtual clusters, there is an option to only get this
SSH adjustment for specific nodes you care about logging in to directly.
For example, you may have 100
compute nodes on a NAT'd network behind the edge nodes. You wouldn't care
about known_hosts adjustment for those so you can turn that off on a case
by case basis.

Before submitting to the cluster, we need the grid tools to trust the
middleware on the headnode.
The head node has been configured to create a self-signed host certificate.
Grab it and add it to the embedded trusted cert directory like this: