To edit the list of authorized users of the factory service, add DNs to $GLOBUS_LOCATION/etc/workspace_service/workspace-grid-mapfile

Add a DN to the list in normal Globus fashion (if the DN has spaces in it, use quotes around it). The gridmap authorization module requires a username mapping, but it is irrelevant to this service, so using e.g. "fakeuser" for each DN entry is OK. We support actual grid-mapfiles instead of simple access control lists for maximum compatibility with predeployed installations.

The "groupauthz" plugin allows for basic group policies, you can add identities to groups and then control how much time each member is allowed to expend, etc.

Other (attribute based) authorization methods are available via the plugin system. That page also explains the creation process in detail including rich authorization options.

After a workspace is created, only the creator may manage the WSRF resource. This is configured programmatically for each workspace, so no grid-mapfile for the workspace service is needed, just the factory.

There are currently two service implementations, xenlocal and xenSSH. The former is simple to configure, but only allows deploying workspaces on a single node (where both the frontend and backend must be installed; so, the frontend interacts locally with the backend). xenSSH, on the other hand, allows the Workspace Service to manage a pool of nodes (the "resource pool"), with the frontend controlling the backend through SSH. In this implementation, the service keeps track of the what resource are available at the current time, adding and subtracting the resources used, keeping a view of what is available at the different hypervisor nodes. In this version of the service, this only tracks the RAM available for VMs at the node and what networking associations each node can support (they can be different from node to node).

To choose the service implementation, edit the jndi-config.xml file. Find the implemention entry under the WorkspaceService section. The value of this entry determines the service implementation.

If you choose XenSSH, take into account that the user running the GT4 container on the frontend node must have passwordless SSH access (e.g., by using SSH keys) to the nodes that belong to the resource pool, and vice versa.

The $GLOBUS_LOCATION/etc/workspace_service/resourcepools directory can contain files that represent resource pools.

If you want to change this directory, alter the "resourcepoolDirectory" configuration of the "SlotManagementAdapter" section in the jndi-config.xml file.

The pool file format is currently very simple: for each node in the pool, list the hostname and the amount of RAM it can spare for running guest VMs.

Optionally, you can also specify that certain hosts can only support a subset of the available networking associations (see the file comments for syntax).

If you change these configuration files after starting the container, only a fresh container reboot will actually incur the changes.

The workspace service can allocate IP addresses from pools of addresses (called associations) for the Allocate and AllocateAndConfigure networking methods. See this section of the interface descriptions for background information.

These pools are configured by listing available addresses in files. The name of the file is the association name, and the directory to find all such files is, by default, $GLOBUS_LOCATION/etc/workspace_service/associations

If you want to change this directory, alter the "associationDirectory" configuration of the "NetworkAdapter" section in the jndi-config.xml file.

The service is packaged with one sample association file, public, which can be found in the default associations directory. It contains the syntax explanation as comments. Currently there is no script to auto-generate such files from higher level logic, each entry must be specified manually or generated via a quick script of your own.

If you change these configuration files after starting the container, only a fresh container reboot will actually incur the changes.

Currently, the factory can be configured with three simple policies concerning workspace deployment. Each value is listed in the WorkspaceFactoryService section of $GLOBUS_LOCATION/etc/workspace_service/jndi-config.xml

The defaultRunningTimeMinutes value is used if the DeploymentTime element of the deployment request is not specified.

The maxRunningTimeMinutes value is what the DeploymentTime element of the deployment request may not exceed.

The WSRFResourceMinutesPastRunningTime value configures the default termination time of the WSRF resource representing the workspace. When a workspace is shutdown, its representation is not terminated (one reason being that it can be started again). This value is added on to the running time and is currently only configurable at this location.

The maxGroupSize configuration what the NodeNumber element of the deployment request may not exceed. If this is zero, negative, or missing, there will be no limit to group request size.

The optional architecture value can be one of the JSDL ProcessorArchitectureEnumeration values such as "x86". If you are running Xen on other architectures, this should be changed appropriately.

The optional vmm value will currently be Xen.

The optional vmmVersions value can be a comma separated list of one-word strings (deciding on values to use is a deployment issue within VOs).

For more information about the deployment request, see the interfaces documentation.

For more information about richer authorization options, see the plugins documentation for discussion. The service installation includes a "groupauthz" module that is included but not activated by default.

By default, the workspace service does not have any staging adapters configured. Staging adapters allow clients to send an optional stage-in and/or stage-out request with the workspace creation request, and the workspace service will handle making this happen.

To enable the HTTP adapter, simply uncomment the HTTP configuration section in the jndi-config.xml file. Fill in the configuration for the image node hostname that will be the target of the HTTP transfers. If this is not localhost, the adapter will use SSH and therefore need passwordless key access as in the resource pool model's case.

To enable the RFT adapter, you must install the RFT plugin (available on the workspace downloads page) in addition to uncommenting the RFT adapter configuration section in the Workspace Service's jndi-config.xml file. The RFT service can be hosted in the same container but it is not required: the service URL is always passed along with the staging request.

This version of the workspace service does not support unauthorized client kernels. As such, the backend configuration file lists the authorized kernels, which must be inside the backend directory tree (by default, in the /opt/workspace/images directory). Copy any kernels you wish to use to that directory, and list them in the guestkernels option under the [images] section of the configuration file. By doing this, clients can choose from these kernels in the metadata, but they must already exist at the hypervisor node and must be in the guestkernels list.

With Xen, for each NIC on the hypervisor node, it is typical to create a corresponding bridge such that guest virtual machines may be bridged to each NIC. This allows workspaces to be on different networks or allows spreading out of the networking load (in the case where the hypervisor's multiple NICs are on the same network).

Support for multiple physical and virtual NICs is present in this version, mapped in the grid context in terms of a networking association string. A client will specify the required association in the metadata, assuming the deployment nodes support that association (otherwise, a creation fault will be thrown). An association is created by configuring an entry for it in the workspace-control configuration file. This should match the service association configurations.

For example, the node could have two physical NICs, one bound to a private LAN and one bound to the Internet. To accomodate virtual networking cards being bound to both NICs, a site admin could create two bridges, xenbr0 and xenbr1. Then an association would be configured for each bridge, e.g., one called "public" and one called "private" for example (a typical configuration).

In the sample workspace-control configuration file, find the association_ settings in the [networking] section. If xenbr0 is the 'public' interface, add this line:

association_0: private; xenbr0; vif0.0 ; none; 192.168.0.0/24

This specifies that there will be an association called 'private' with bridge 'xenbr0' with MAC address prefixes of 'none' (which means allow the service to decide) given to virtual NICs bound to this bridge and with an authorized IP range of 192.168.0.0 to 192.168.0.255.

The third field lists the interface of the NIC that is listening for DHCP requests. This is the interface that DHCP requests originating from workspaces should be allowed to broadcast to. Directing the request to a specific interface prevents DHCP requests from being broadcast to other workspaces as well as to the real network. You can doublecheck what vif is on what bridge by running "brctl show". Normally you'd run the DHCP server in dom0 and the defaults are like so:

xenbr0 - vif0.0
xenbr1 - vif0.1
xenbr2 - vif0.2

You are not required to run the DHCP server in dom0 as the workspaces' DHCP request broadcast can be directed to any interface, but currently to run it in another domain would require altering the dhcp-config.sh callout to work remotely (this would not be hard for you to do, grep for "dhcpconfigpath" in the xen_v2.py module and prepend ssh parameters, for example).

Note: if you only have one bridge for virtual network cards, a simple configuration would be to list one association like so:

association_0: default; none; 1.0.0.0/16

Note that no bridge name is given, the default bridge as determined by Xen will be used. Note the IP range is fake; if you want to not keep track of workspace IP assignments (to prevent conflicts) or to not check if a requested IP setting is valid for the bridge, ensure the check_ip_ranges, track_MAC_assignments, and track_IP_assignments settings are set to 'false'.

This version of workspace-control has a simple, configurable blankspace creation script. This can be edited to suit your needs but right now can only handle one creating one type of filesystem per deployment. This is ext2 by default. In the future, the filesystem type may be included as part of the client's request.

The script's default location is /opt/workspace/bin/blankcreate.sh

Recommendation is to start with new configuration file template and move old configurations to it. No names or semantics have changed.

An extra sudo rule is required for the mount-alter.sh tool. The workspace-control installer will print the exact line you need to enter, there are also samples in the new configuration template.

Association configurations may no longer include 'none' for the hostnames. Each address requires a unique hostname (see the changelog, this is for DHCP delivery to work correctly) but it does not necessarily need to resolve via DNS.

There were structural changes in the jndi-config.xml file this release, so it is highly recommended to start with the TP1.3 example file and move old settings manually into it.

Association and resource pool configurations are now read in at container startup time in a different way. See the networking and resource pool configuration sections for more details.

The old files will not work in TP1.3, you need to remove the last two tokens from each line, the 'certfile' and 'keyfile' fields.

The worksp.conf file does not need to be altered, the TP1.2.3 can be re-used, but several configurations are never consulted in this version.

Certificate and keyfile staging functionality was removed from the service. The 'mounttool', 'mountdir', and 'tmpdir' configs are no longer consulted by workspace-control. They have been removed from the sample configuration file.

If you were enabling that functionality, the accompanying sudo rule for the mount tool can be removed as well.

'family' and 'find_maxvmram' were removed from the sample configuration file.

As mentioned above, note that it is possible to use a TP1.2.3 workspace-control configuration file with a TP1.3 (or TP1.3.1) workspace-control, the extra configurations will just be ignored by the TP1.3.1 workspace-control program.