There are ten design objectives listed here, and three constraints. They were laid out before any Legion code was written and have been carefully considered at each stage.
Objectives
- Site autonomy
Legion is not a monolithic system, but is composed of resources owned and controlled by a variety of organizations. Since these organizations require control over their own resources, Legion can not dictate how much of a particular resource can be used, when it can be used, or who can use it. - Extensible core
We cannot predict all of the needs of current and future users. We must build Legion with extensible and replaceable components that permit Legion to evolve over time and allow users to construct their own mechanisms and policies. - Scalable architecture
Legion cannot rely on a centralized structure. If the system is to eventually encompass millions of hosts, it must use a scalable architecture. - Easy-to-use, seamless, computational environment
We must mask the complexity of the hardware environment and the communications synchronization of parallel processing. Users should not be aware of machine boundaries. Compilers, in cooperation with run-time facilities, should manage the environment. - High-performance via parallelism
We must support easy-to-use parallel processing by means of large degrees of parallelism (this includes task and data parallelism and their arbitrary combinations). - Single, persistent, name space
One of the most significant obstacles to wide-area parallel processing is the lack of a single name space for file and data access. Existing multiple disjoint name spaces makes writing applications for multiple sites very difficult. Legion therefore uses a single, persistent, name space. - Security for users and resource owners
We cannot replace existing host operating systems (see below), but we can ensure that existing mechanisms are not weakened by Legion. Legion does not define a security policy or requires a "trusted" Legion, but offers mechanisms for users to manage their own security needs. - Management and exploitation of resource heterogeneity
Legion must support interoperability between heterogeneous hardware and software components, as well as exploit architectural strengths as possible when making scheduling decisions and policy. - Multiple language support and interoperability
Legion applications will be written in a variety of languages, and heterogeneous source language application components must be integrated. We must also support legacy codes. - Fault tolerance
At any given moment in a large system, several hosts, communication links, and disks will fail. Legion must be able to handle their failures and dynamic reconfiguration.
Constraints
- We cannot replace host operating systems
Organizations cannot allow their operating systems to be replaced. That would require rewriting applications and retraining users, as well as raising compatibility problems with other machines in the organization. - We cannot legislate changes to the interconnection network
We must assume that network resources and protocols currently in use will not change. While this means accommodating operating system heterogeneity, we must accept the available resources. - We cannot require the Legion run as "root"
To protect their resources, most users will want to run Legion with the fewest possible privileges.
| Link | Description |
 | |
| Overview | A general look at Legion |
| Objectives and constraints | Legion's design objectives and restrictions |
| Applications | Adapting and running Legion applications |
| Architecture | Legion system architecture |
| High-performance computing | Using Legion to get high-performance computing |
| Scheduling | Scheduling and resource management |
| Security | Legion's security philosophy and model |
