WikiPrint - from Polar Technologies

Implementation Path

The New DETER APIs replace what is essentially a widened Emulab interface with powerful additional features implemented on top of it with an integrated system that incorporates the new features into a principled and powerful API. In addition the administration of users and rights has been significantly expanded to enable more interesting and powerful sharing of resources and experiments between users.

As this system is implemented, DETERlab must preserve the existing web interfaces for its current users. Thousands of users, including students, depend on the existing feature set and resources to conduct research and teach classes. This page discusses the challenges and plan in moving the new features forward without overly disrupting existing service.

The System Architecture

The new system architecture (below) includes the existing Emulab software as a resource allocation system.

System Diagram

All the systems outside the red rectangle will require to be created or modified to support the new API. In many cases we will derive the new, general structures from existing ones.

The new system will primarily be run by the DETER System box - a server running on the current boss machine. It differs from the current interfaces in that it:

The current Emulab implementation carries out some of those functions now, albiet less powerfully. The initial DETER system implementation will use the legacy implementations of those features (in all cases the new features are a superset) and implement and expose enhanced functionality as needed. In the long run, the only features to be provided by Emulab will be allocation of computers resources and providing physical connectivity.

Policy and Permissions

The policies of the DETER interface are more fine-grained and more complex than existing Emulab policies. We will be using the ABAC authorization control system to separate the authorization semantics from the implementation and to allow independent auditing and reconfiguration of that system.

The major thrust of this part of the implementation is providing administrator tools to read and edit the policies, expressed in ABAC, that underly the system. In addition, we will be producing a policy database that will manage the system's interaction with policy.

We are planning to design our own policy management system, based on the ABAC grouper system we demonstrated at GEC 14.

The policy system can be designed implemented and enhanced without being in the critical path of creating the new DETER interface.

The DETER Beginner Web Interface (DBI)

To demonstrate the power of the testbed API to provide multiple views of DETERlab, a group is constructing an alternative teaching/introductory interface using the DETER testbed API. The development of the new DETER system must support this new interface as it forms.

Roadmap

The roadmap for development is:

  1. Implement stubs and passthrough code that allows access to existing functionality through the DETER testbed API. This is a 2-3 week prospect and is done in order to
  2. Migrate user and permissions function into the new interface - 2 weeks
  3. Build the in-testbed processes that use the containers API for configuration - 1 month
  4. Complete integration of testbed API and containers API - 2 weeks
  5. Allow dual testbed use through either interface - new users on new interface
  6. After about 1 month, shut down old interfaces.