Nimbus

DEPRECATED: The most recent version is Nimbus TP2.2

Version TP1.3.2 - VWS Technology Preview 1.3.2

This is a technology preview of the virtual machine based Workspace Service (VWS). The workspace service provides a gateway to a set of resources configured with the Xen (2.0.7 or 3.x) implementation of virtual machines.

See the Features page for general information on VWS functionality. See below for detailed documentation options that explain the functionality and configurations in detail.

You can download the software from the downloads page.

A set of VMM resources may be managed entirely by the workspace service or alternatively integrated with a site's resource manager (such as PBS) using the workspace pilot. This way a dual use grid cluster can be achieved: regular grid jobs can run on the VMM node with no guest VMs, unless the node is at that time allocated to the workspace service. The site resource manager maintains full control over the cluster and does not need to be modified. For more information, see Flying Low: Simple Leases with Workspace Pilot.

Documentation

Acknowledgements

We would like to thank Josh Boverhof, David Bartle, David Grundy, Ian Gable, and Mauricio Tsugawa for their help with this release.

Changes in TP1.3.2 (vs. TP1.3.1)

• Introduction of the cloud configuration and cloud client for user friendly client access to the workspace service.

• Introduction of the "groupauthz" authorization plugin for typical configurations including the cloud setup.

• Clients may now send customization tasks with request, files on the image will be replaced with the content. The cloud client, for example, is set up by default to send a customization request that sets up the workspace's "/root/.ssh/authorized_keys" file.

• Clients can request an alternate unpropagation target to save a template VM into a new personal copy. This new URL may be requested both at creation time and on the fly in a unpropagate request.

• Centralization of MAC address allocations to the central workspace service. This allows all backend configurations files to be identical. Older/advanced configurations are still possible but not recommended unless necessary.

• Hard disk images are now supported (client may bring a matching kernel along).

• Various client enhancements including internal organization, cleaner output, and new commandline options.

• A few bug fixes.

• There was a WSDL update: additions, changes and new namespaces. The base namespace for workspace schemas is now http://www.globus.org/2008/03/workspace/

• See the Cloud Guide for an overview of a new set of configurations/conventions that allow for clients to get up and running in minutes even from laptops on NATs. Currently this comes at the cost of obscuring some features like group deployments and multiple NICs.

• Centralized MAC address allocations to the workspace service. This allows all backend configurations files to be identical. Older/advanced configurations are still possible but not recommended unless necessary.

  There is a new configuration in the jndi-config.xml file that allows the administrator to define the valid prefix for MAC address selection. See WorkspaceFactoryService -> NetworkAdapter -> macPrefix

  Once an IP is assigned a MAC address (during service initialization) it remains with that IP as long as it is configured as part of the network pools. This ensures that local network devices can cache MAC/IP bindings without needing to be manually cleared (no need for unsolicited ARP reply to guarantee connectivity).

• Introduction of the "groupauthz" plugin. This comes directly with the workspace service (no separate plugin installation is necessary) but it is not enabled by default. This authorization plugin supports different policies for different group members which you organize by inserting identities into different group files.

  The plugin can enforce the following policies. The request data to check is determined on a per-request, per-client basis. The limits are defined on a per group basis (every caller identity must be a part of a group).

  • Maximum currently reserved minutes at one point in time. If the caller has two other workspaces with 10 hours scheduled for each, the value being checked against this policy would be 20 hours plus whatever time the current request is.
  • Maximum elapsed and currently reserved minutes at one point in time. If the caller has one other workspace with 10 hours scheduled and 80 hours of recorded past usage, the value being checked against this policy would be 90 hours plus whatever time the current request is. This is the all-time maximum usage cap.
  • Maximum number of running workspaces at one point in time.
  • Maximum number of workspaces per request (the largest group request possible).
  • The image node that must be specified.
  • The image node base directory that must be specified.
  • Support for identity-hash based image subdirectories (see the cloud setup documentation to understand this convention).

  Each policy can be set to disabled/infinite for specific groups if you desire.

• Arbitrary file customization tasks may be sent with the workspace creation request. The image is mounted on the VMM and the contents of the task are placed into the specified file.

  This requires mount-alter.sh support on the backend which expects the mount -o loop construct to work without specific filesystem selection. i.e., this will not support workspaces with filesystems that the VMM kernels do not support.

  This requires three new jndi-config.xml configurations:

  • WorkspaceService -> home -> localTempDirectory
  • WorkspaceService -> home -> scpPath
  • WorkspaceService -> home -> backendTempDirectory

• Inclusion of alternate unpropagation URL. This allows the client to specify the target URL for where the workspace is unpropagated. It can be specified as part of the creation request or overriden after deployment. If the default shutdown mechanism was to destroy the workspace, this can still be used (with shutdown-save) to cause unpropagation to the given URL.

• Authorization enhancement to support late-specified alternate unpropagation URL. An operation to check the contents of a post-deployment alternate propagation URL request was added to the authorization callout interface.

  This can be used to filter out invalid requests. For example, the groupauthz plugin discussed above will use the same logic here for image repository policy checking that it does at create time. Previously, the authorization callout had only one operation which was called at creation time only.

• Fault information can now be stored as part of the Corrupted state (for both RP queries and asynchronous state notifications). This will help the remote client debug issues that can arise after a successful factory creation, such as "the file you specified to propagate does not exist at the image repository" etc.

• Various internal changes (see CVS log)

• See the end of the administrator guide for notes on configuration migration to this version from older workspace releases.

• Introduction of cloud-client system. This consists of a wrapper program run from a specific directory setup that contains an embedded globus client installation among other things.

  For more information on the client and setting up a configuration to support it, see the Cloud Guide. To see some examples of end-user commands, see the Nimbus Cloud page.

• The main client's help system was reorganized. For help on options that are specific to an action, use "--help --<name of action>". See the main "--help" output to get started.

• The main client has a new "--exit-state" option that causes modes with subscriptions (in either poll or async mode) to wait for the specified state before exiting with success. If the workspace moves to a terminal state (Corrupted etc.) then this is considered an error. This is aimed at making scripts that wrap the client more effective.

• The main client has a new "--save-target" option whose argument is an override to any previous unpropagation URL. You can use this before or after deployment has succeeded (although it could fail because of authorization issues). See the client's "-h --shutdown-save" output for more information.

• Arbitrary customization tasks are possible by defining them in an optional parameters file. But the main client now also includes a shortcut for the very common task of inserting your SSH public key as the desired contents of the /root/.ssh/authorized_keys file on the VM. See the client's "-h --deploy" output for more information on this new "--sshfile" option.

• Support for post-deployment error printing (faults can now be included as part of Corrupted notifications).

• Status client allows for a bulk query ("in one remote operation, show me a short update of all workspaces I manage at this service").

• Introduction of a base client API which abstracts operations out from the webservices implementation and provides common subscription tools, utility methods, etc. (the main workspace client was internally reorganized to use this API: if you are a client developer you could examine this code for a lot of concrete usage samples).

• (re-)inclusion of mount-alter for file customization tasks. Using this requires an additional sudo rule.

• Fix for a bug where certain NIC bridging problems with a workspace that had more than one NIC would not trip a backout.

• Fix for a bug where the lack of a gateway specification would cause a problem when inserting a workspace's DHCP policy. Lack of a default gateway is legal (and sometimes necessary).

• When DHCP configuration file cannot be found, a more helpful error is printed.

• Files on VMM were not being deleted in one unpropagate situation where they should have been.

• The VM name prefix sent to the VMM has been shortened from "workspace" to "wrksp". String length limits for NIC names were being reached too early ("wrksp" should accomodate workspace IDs in the millions).

• We are including a "foreign-subnet" script that allows VMMs to deliver IP information over DHCP to workspaces even if the VMM itself does not have a presence on the target IP's subnet. This is an advanced configuration, you should read through the script's leading comments and make sure to clear up any questions before using.

  This is particularly useful for hosting workspaces with public IPs where the VMMs themselves do not have public IPs. This is because it does not require a unique interface alias for each VMM (public IPs are often scarce resources).

• Added support for booting hard disk images (pygrub). Resolves enhancement request #5423. Client must specify mountpoint like "hda" instead of "hda1" for this to trigger.

• See the end of the administrator guide for notes on configuration migration to this version from older workspace releases.

• In some situations the sleep() system call that the pilot makes during an unexpected backout situation was returning too early. This syscall been replaced by an alternate implementation that will not fail in those situations.