A primary motivation in Legion's design is flexibility and transparency: programs can be distributed and run on widely distributed resources without the user having to engage in complex, time-consuming negotiations with individual site administrators. However, in order to allow sites to protect their resources against unauthorized or malicious use, Legion provides tools to allow system administrators can maintain their local policies. Final authority over the use of a resource remains with each resource's administrators.
There are three objects for managing your Legion resources: the collection, the scheduler, and the enactor. There are a corresponding set of command-line tools to control the objects. A more detailed discussion of these objects is in section 8.0 of the Developer Manual, but in brief they carry out the following functions.
There are a several commands that can be used to set up an individual Legion's scheduling process and a class's or instance's host and vault placement policy. Please see page 45 in the Reference Manual for details of these commands' syntax and usage.
The legion_config_scheduler utility configures a basic Legion scheduler's helper objects. Use it to assign a particular collection and enactor to a basic Legion scheduler or vice versa. It can also be used to query which helper objects have been set for a basic Legion scheduler. The example below shows the LOID of the default scheduler object's enactor.
This legion_set_scheduler command sets a specific class's default scheduler. The class will then use its assigned scheduler object to determine which hosts and vaults should manage its instances (i.e., determine placements for the class's instances). The example below sets SchedulerFoo as the default scheduler object for ClassFoo.
The legion_set_scheduler_policy command sets a class object's policy for using its default scheduler. There are two policy options, which determine whether or not the class uses its default scheduler if the scheduler object is not active. Depending on its type, a class may require a policy which does not use an inert scheduler. If not, classes should have a default placement available
There are three commands for controlling the collection object. Objects can be added with legion_join_collection. The example below adds HostFoo to the default collection, although any Legion object can be added to a collection.
The legion_query_collection prints a list of which objects are currently part of a given collection. The legion_query_collection command uses MESSIAHS Interface Language (MIL) query strings (see page 51 in the Reference Manual for query string examples and page 127 in the Developer Manual for relevant MIL interfaces). The example below returns the list of Linux host objects that are part of the default collection.
A subcollection is a normal collection object that is polled by another collection object (called the parent collection). This arrangement allows for faster and more efficient resource information gathering, since you can have several subcollections monitoring small groups of resources. A parent collection can have more than one subcollection and a subcollection can have more than one parent as well as its own subcollections. A parent runs one or more MESSIAHS-type queries on a subcollection (see page 51 in the Reference Manual for query string examples).
To create a parent-subcollection arrangement, use the legion_add_sub_collection command. You must specify a parent and a subcollection (both collections must already exist). You can also specify a query to be started by the parent on the subcollection. If no query is specified, the default value of 'true' will be used. You can run this command multiple times to start multiple queries on a single subcollection.
Please see Scheduling support in the Reference Manual for more information about using these commands.