The DFA Plugin Architecture
Access controllers are customized to the underlying testbed technology and testbed policies of a resource provider. In order to connect custom access controllers we define an interface for creating and manipulating the testbed topologies that experiment controllers use to talk to access controllers. Access controllers can be integreted into the fedd codebase or be stand-alone controllers that are accessible through these interfaces.
Key to these interfaces is a topology description language, topdl, that defines experiment topologies and sub-topologies at a level of abstraction that can be specialized when necessary. We discuss topdl below after defining the basic interfaces and terminology.
If you are interested in developing a plug-in, you should proceed to the detailed interface description when you have finished this one. There is another link to that page at the bottom of this one.
Operations
The following operations are valid on an access controller:
- Grant Access
- Configure the local testbed to allow the researcher to allocate resources. The request includes the researcher's credentials and optionally an estimate of the resources required and allocation timeframe. This allocation is bound to a fedid. This operation allows a testbed to configure itself - for example an emulab-style testbed may add projects or user accounts at this point.
- Start Segment
- Make of resources to the experiment and bind it to the allocation created above. At this point the testbed resource allocation system is run on the specific resource topology requested. This is an initial allocation, so any testbed-specific operations used in creating a new allocation are carried out.
- Terminate Segment
- Remove the resources created above. Notice that the fedid-bound allocation still exists, so that new resources can be allocated to it.
- Remove Access
- Release the fedid-bound allocation. At this point a testbed may reclaim any local resources bound to that allocation outside the experiment resources.
These are encoded as the RequestAccess, ReleaseAccess, StartSegment, and TerminateSegment operations in the web service interface.
In the future we will be expanding these operations to include support for more informantion and manipulation of federated experiments, inclucing manipulating nodes in an experiment and changing experiment topology.
Topology Description Language
DETER's topology description language, topdl, is described in more detail elsewhere. This section mentions some of the topdl attributes used internally by the federation system.
Attribute Conventions
Though we expect attribute conventions to evolve, currently the following entension attributes are understood. Several are being used to bridge from the existing experiment description language to current topdl, and are somewhat emulab-specific.
- failureaction
- What the underlying testbed should do if this node cannot be reserved or configured. Choices are fatal or nonfatal.
- osid
- The local emulab operating system image. This will become less common as more plugins are capable of mapping from operating system parameters into local image name, but can be used as a low-level escape.
- testbed
- The experiment controller's name for the testbed this node will be placed on. This is in place to allow native topdl descriptions to be accepted by experiment controllers - it's not needed by access controllers. As the full experiment description language evolves, this may move into som part of that language or become a standard topdl attribute.
- type
- The local emulab machine type. This will become less common as more plugins are capable of mapping from CPU/storage parameters into local machine type, but can be used as a low-level escape.
The following attributes appear in topology descriptions for use by local emulabs in configuration:
- active
- Attached to a portal computer. If true, this portal initiates connections to the peer.
- dragon_vlan
- If assigned, the VLAN tag on which this node will communicate. The name will change.
- domain
- Attached to a portal computer. This is the DNS domain of the local emulab resources.
- ip4_address
- The IP version 4 address of the interface that the attribute is attached to as a dotted decimal.
- masterdomain
- Attached to a portal computer. The DNS domain of the emulab exporting its environment. Used to connect services and forward traffic.
- masterexperiment
- Attached to a portal computer. The emulab project/experiment name of the environment being exported from the master testbed. Used to connect services.
- masteruser
- Attached to a portal computer. The emulab user that alloacted the exported environment on the master. User to connect to services.
- peer
- Attached to a portal computer. DNS name of the portal node used to bridge services and traffic.
- peer_segment
- Attached to a portal computer. Fedid of the allocation in which the peer portal lives.
- portal
- True if this is a portal computer added by the experiment controller
- portal_type
- Attached to a portal computer. Specifies whether this portal exports services, forwards traffic, or both.
- smbshare
- Attached to a portal computer. The SMB/CIFS share used to export local file systems (if any)
- startup
- The startup command to federate the computer.
People with an interest in plug-in development will want to continue to the detailed interface description