| | 1 | [[TOC]] |
| | 2 | |
| | 3 | = DETER Containers API = |
| | 4 | |
| | 5 | The containers API is a set of simple and extensible operations to control testbed elements. It is primarily a way for the testbed control to communicate with experiment elements. As such it is not usually visible to users. For power users we do supply a passtrough interface so that they can access specializations of containers. |
| | 6 | |
| | 7 | == Testbed to Containers Operations == |
| | 8 | |
| | 9 | Each of these is sent to a container controller with a distinct address. A controller is often responsible for more than one container. In general we attempt to scale the number of controllers with the number of physical resources so that the testbed can communicate with them directly. In very large testbeds, there may be interconnected controllers acting as relays. |
| | 10 | |
| | 11 | All the control commands can be applied to multiple containers simultaneously. |
| | 12 | |
| | 13 | There are only a few things all containers can do: |
| | 14 | |
| | 15 | Begin operating as an experiment element. For a computer, boot; for a flux capacitor, begin travelling in time: |
| | 16 | |
| | 17 | * '''Service:''' Containers |
| | 18 | * '''Operation:''' start |
| | 19 | * '''Input Parameters:''' |
| | 20 | * '''Input Parameters:''' |
| | 21 | * NameRE - an optional list of regular expressions to match against container names |
| | 22 | * Types - a list of container types to restrict the operations to |
| | 23 | * '''Return Values:''' |
| | 24 | * None |
| | 25 | |
| | 26 | Become quiescent. Only containers API requests will work on a stopped container |
| | 27 | |
| | 28 | * '''Service:''' Containers |
| | 29 | * '''Operation:''' stop |
| | 30 | * '''Input Parameters:''' |
| | 31 | * NameRE - an optional list of regular expressions to match against container names |
| | 32 | * Types - a list of container types to restrict the operations to |
| | 33 | * '''Return Values:''' |
| | 34 | * None |
| | 35 | |
| | 36 | Set up the container's internal state. (For a computer, establish accounts and mount filesystems; for a flux capacitor, set travel rate and destination date). Configuration can be a multi-step process to facilitate configuring many containers at once. A base configuration can be distributed broadly and sub-configurations passes to specialized elements. The semantics of combining configurations can vary per-container-type, but are generally a sequential application of configurations. |
| | 37 | |
| | 38 | * '''Service:''' Containers |
| | 39 | * '''Operation:''' configure |
| | 40 | * '''Input Parameters:''' |
| | 41 | * NameRE - an optional list of regular expressions to match against container names |
| | 42 | * Types - a list of container types to restrict the operations to |
| | 43 | * ConfigData - an opaque field used to configure the container |
| | 44 | * Commit - a flag indicating that this is the configuration is complete and the container can begin applying it |
| | 45 | * '''Return Values:''' |
| | 46 | * None |
| | 47 | |
| | 48 | Containers can describe themselves. Again, controllers can collapse multiple like containers into one operation. |
| | 49 | |
| | 50 | * '''Service:''' Containers |
| | 51 | * '''Operation:''' describe |
| | 52 | * '''Input Parameters:''' |
| | 53 | * '''Input Parameters:''' |
| | 54 | * NameRE - an optional list of regular expressions to match against container names |
| | 55 | * Types - a list of container types to restrict the operations to |
| | 56 | * '''Return Values:''' |
| | 57 | * An array of structures with the following fields |
| | 58 | * Names - an array of strings naming containers |
| | 59 | * Type - a string giving the container type |
| | 60 | * ConfigFormat - the configuration format that the container supports |
| | 61 | * Interfaces - a list of pre-defined extension interfaces supported by the container. If "custom" is given ExtendedOps is required |
| | 62 | * ExtendedOps - an optional list of URIs from which the WSDL for custom extended operations can be gathered |
