An Environment is a logical grouping of objects with a shared variable space and applied policies. Environments can hold virtual machines, physical machines, jobs, reservations, and/or nodes. Environments can also be nested inside other environments.

VARIABLES

Triggers attached to objects will be able to have access to variables of all immediate parent environments of the object that it is attached to. If they export their trigger variables, these will also be pushed up to the environments. Note that this does mean that variables can be overwritten if two triggers write to the same variable. This is currently only implemented for triggers attached to jobs and reservations.

FLAGS

• DestroyWhenEmpty - When the environment is empty, it will be destroyed. Called in MVCRemoveObject, so it won't destroy an empty environment when it is created.
• DestroyObjects - When the environment is destroyed, any reservations, jobs, and VMs in the environment will also be destroyed. This is recursive, so any objects in sub-environments will also be removed. Nodes are not removed.
• Workflow - Designates this environment as an environment that is for workflows. This flag is set when generated by a job template workflow. Job template workflow jobs can only be attached to one workflow environment.

SOFTWARE REQUIREMENTS

Functional and Behavioral Requirements

Phase one is an attempt to reproduce the VPC behavior (vpc object with reservations) with a environment and generic system jobs. This means that a user will submit a job into a job template. The job template will consist of one or more dependencies for both before and after the job. The submitted job, as well as the jobs created automatically by the template will belong to a single environment, much the same way that reservations belong to a VPC. The environment will mainly be used as a namespace for variables that are consumed by the various triggers on the generic system jobs.

We also to have implemented the command that will be used to query and control environments: mvcctl. Initially this command will be used to query the environmentVE much like the "mschedctl -l vpc" command is used to query VPCs. It will report back information about the jobs that are part of the workflow. The mvcctl command will also allow for destroying the entire generic system job workflow, much like "mschedctl -d vpc" works for VPCs.

Phase one will have the environments generated automatically when the job is submitted. It will not handle the manual creation of an environment and the manual insertion of jobs into the environment.

Also, there is some behavior that is present in VPCs that will not be enabled for phase one generic system jobs. For example, reservations within VPCs can be modified and can grow and shrink. Jobs in a workflow will not allow for growing and shrinking or modifying.

Any behavior that is not currently exhibited by VPCs will not be the focus of phase one.

ASSUMPTIONS

Phase one assumptions are that each job in the workflow will be the same size and will run on the same resources (inherit).

DEPENDENCIES

Phase one depends on job templates extensively. Job templates will define the workflow including the prologue and epilogue actions. Phase one will require that job templates can be created and destroyed using the "mjobctl -T" command.

IMPLEMENTATION

The majority of the environment code is in src/moab/MVC.c. This is in v6_1.

Most of the resource ownership is done with mln_t structures. The VE has a separate linked list for jobs, nodes, rsvs, vms, and sub-environments. Also, each object that can be owned by an environment has a linked list called ParentVCs. MVCAddObject and MVCRemoveObject will take care of adding/removing the environment in the object's ParentVCs and adding/removing the object in the environment's linked list. These two functions are the only way that these links between objects and environments should be made.

Currently, if you modify the variables on a job, they will be modified on any parent environments. We may want to change this so that this only happens in certain cases (if the environment was created as part of a job template, etc.).

Again, MVCAddObject (mvcctl -a) and MVCRemoveObject (mvcctl -r) are the only way an object should be added/removed from a environment.

IMPORTANT FUNCTIONS

Creation/Removal

• MVCAllocate() - Allocates an environment and gives it a name (user can specify a description, but not the name).
• MVCRemove() - Destroys links that an environment has and calls MVCFree. Removing an environment will also remove sub-environments, but it will not remove any other children. So, sub-environments will be destroyed, but nodes and jobs and such will still exist outside of the environment.
• MVCFree()
• MVCFind()
• MVCGenerateName() - Creates a unique name for an environment
• MVCIsEmpty()

Modify

• MVCAddObject() - Adds an object to the environment (and the environment as a parent to the object)
• MVCAddObjectByName()
• MVCRemoveObject() - Removes the object from the environment (and the environment as a parent)
• MVCRemoveObjectByName()
• MVCSetAttr()

Checkpointing

• MCPStoreVCs()
• MCPLoadVC()
• MVCToXML()
• MVCAToMString()
• MCPSecondPass() - Does a second pass of checkpoint info to make connections

Display

• MVCShowVCs() - Shows environments for blocking mvcctl -q
• MVCIsSupportedOType() - Helper function that says if an object type can be contained in an environment
• MVCTransition()

Access Control Lists (ACLs)

Virtual environments support access control lists (ACLs). The ACLs are simplified compared to the ACLs of Moab. Credentials on the ACL have full rights to the VE, except for changing ownership. ACL classes follow the ACL syntax for most Moab objects.

mvcctl -m ACL+=USER:jgardner vc1