| | 15 | 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. |
| | 16 | |
| | 17 | 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: |
| | 18 | |
| | 19 | * Separates web interfaces from operational interfaces |
| | 20 | * Manipulates more complex experiment object that include |
| | 21 | * Descriptions of operations to perform |
| | 22 | * Experimental dataflow |
| | 23 | * Topology expressed in containers |
| | 24 | * Supports a more expressive and flexibly permissions system |
| | 25 | * Access to the same experiment allowed by multiple projects |
| | 26 | |
| | 27 | 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. |
| | 28 | |
| | 29 | == Policy and Permissions == |
| | 30 | |
| | 31 | The policies of the DETER interface are more fine-grained and more complex than existing Emulab policies. We will be using the [http://abac.deterlab.net ABAC] authorization control system to separate the authorization semantics from the implementation and to allow independent auditing and reconfiguration of that system. |
| | 32 | |
| | 33 | 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. |
| | 34 | |
| | 35 | We are planning to design our own policy management system, based on the ABAC grouper system we demonstrated at [http://groups.geni.net/geni/wiki/GEC14Agenda GEC 14]. |
| | 36 | |
| | 37 | The policy system can be designed implemented and enhanced without being in the critical path of creating the new DETER interface. |
| | 38 | |
| | 39 | == The DETER Beginner Web Interface (DBI) == |
| | 40 | |
| | 41 | 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. |
| | 42 | |
| | 43 | == Roadmap == |
| | 44 | |
| | 45 | The roadmap for development is: |
| | 46 | |
| | 47 | 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 |
| | 48 | * support development of the DBI |
| | 49 | * allow simultaneously creating a new minimal access web interface that will become the default interface |
| | 50 | 2. Migrate user and permissions function into the new interface - 2 weeks |
| | 51 | * At this point parallel policy development tool development can begin |
| | 52 | 3. Build the in-testbed processes that use the containers API for configuration - 1 month |
| | 53 | * A transition plan for existing images is also required here |
| | 54 | 4. Complete integration of testbed API and containers API - 2 weeks |
| | 55 | * At this point a transitional web DB will be in place |
| | 56 | 5. Allow dual testbed use through either interface - new users on new interface |
| | 57 | 6. After about 1 month, shut down old interfaces. |
