Tutorial:
Introduction to Legion context space
Table of Contents
|
|
$ . ~legion/setup.sh
or
$ source ~legion/setup.cshThe following style conventions are used in these tutorials:
| What is context space? |
These string names are called context names and you organize them in a hierarchy of contexts in Legion's context space. Context names are organized in sets of contexts and subcontexts, just as Unix files are organized in sets of directories and subdirectories. New Legion systems have a prebuilt context space for convenience, but you can rename and rearrange all or part of your context space as appropriate. You can run programs, use far-flung resources, and take advantage of Legion's other features via your context names.
You can see an example of context space in action by looking at the vanet context space. You can login as a guest user (or, if you have a vanet account, you can login with your id and password) and see how we've set up our testnet's context space. Your system's context space will probably not look like this, but you can get a sense of how it fits together.
Context space is a way of organizing Legion objects and can be thought of as a network-wide transparent file system. It is similar to Unix's system of directories and files but while Unix space is location specific, context space can potentially include objects anywhere in Legion. You maintain your own context space, organizing it to reflect your needs.
You will probably do most of your Legion work in context space, so it is important to be familiar with the geography of your system's particular context space and to feel comfortable negotiating that space..
| What am I looking at? |
Figure 1: Contents of a new Legion system context space (* The /users/admin context is used only in secure systems. If your system administrator has not enabled Legion security this context will not appear in your system.)
![]() |
Think of the different levels of context space as directories and sub-directories. Each of the four contexts in Figure 1 can hold sets of sub-contexts, just as Unix directories hold sets of subdirectories. Context names are organized with contexts, just as Unix files are organized with directories. Context path names use Unix-style slash (/) as a default, so the examples here follow that style (e.g., the full context path name for BootstrapHost in the system shown in Figure 1 is /hosts/BootstrapHost). It is possible to change Unix-style slash to the DOS-style backslash (\) via the primitive context manipulation routines provided by the Legion library.
Figure 1 shows four sub-contexts: class, hosts, vaults, and home. These in turn contain the default context names of the basic elements of a new system: class contains context names of particular classes of Legion objects, hosts contains names of the host objects currently in your system, and vaults contains names of the vault object currently in your system. The home context is initially empty.
When newly installed, hosts contains two context names, BootstrapHost and the DNS name of the bootstrap host.1 Both of these names point to the bootstrap host object, which represents the bootstrap host. On the other hand, vaults contains only one context name, BootstrapVault, which points to the bootstrap vault object. (Please click here for more information on host and vault objects.)
A new class context contains context names for all of the basic Legion object classes, such as BasicFileClass and ttyObjectClass (Legion classes are themselves objects and can therefore be given context names). All Legion objects are organized into classes and all classes are organized into a hierarchy of metaclasses, with LegionClass as the supreme metaclass. Note that the context space illustrated in Figure 1 does not reflect this hierarchy. This is a key feature of context space: the physical location and organization of Legion objects is unrelated to any user's context space. The objects named in a host context do not have be able to communicate with each other or even to know of each other's existence. They do not even have to be host objects: you can organize your contexts as you wish.
| Organizing context space | Legion object names ![]() More about the LOID ![]() |
Figure 2: Context space
Similarly, a context name can refer to different Legion objects, just as Unix users can use the same name in different directories to refer to different files: in Figure 11 the context path names /User1/ContextA/Foo and /User3/ContextC/ContextC1/Foo refer to different objects.
On the other hand, a single Legion object can have multiple context names in multiple contexts. Figure 3's Foo and Bar refer to a single object, ObjectX, but these names are in two different context spaces.
Figure 3: Single object with multiple context names
It is important to remember that context space does not reflect object space: ObjectX's native location is unchanged by its context path names. User1 might be in the same building as ObjectX or on the other side of the country. Objects named in a single context may actually be hundreds of miles apart.
Beyond the user-level grouping of individual context spaces, linking object groups in graph- or directory-based structures can be useful: just as a Unix directory tree or a collection of hypertext documents provide a logical means to organize information, context space provides a structure for finding and organizing Legion objects. For example, to find a host object running on an IBM SP2, you might enter a context called hosts, then a context called ibm, then a context called sp2, where a list of host objects running on SP2s could be found (in Unix, this would be the equivalent of moving through a series of directories--/hosts/ibm/sp2--to arrive at a directory called sp2).
Legion provides a library interface and utility commands such as legion_context_create, legion_context_add, and legion_ls for manipulating and negotiating context spaces. The Legion library interface provides a Unix-like path interface for expressing navigation through multiple contexts, and Legion command-line tools support path-like naming of objects within context space. Paths are delimited by the "/" character. For example, the path /usr/adam would map to the object named adam within the context named usr.
2. There is another context that represents the user's shell, but it does not appear in object path names nor does it affect the user's movements in context space.[Back]
Other relevant on-line documents:
Last modified: Wed Aug 30 14:23:07 2000
|
[Testbeds] [Et Cetera] [Map/Search]
legion@Virginia.edu
|