| 188 | | |
| 189 | | === Putting It All Together === |
| | 188 | From that point the testbed can issue Clean, Configure, and Start commands to adjust the container state and operation. |
| | 189 | |
| | 190 | === Configuration and Specialization === |
| | 191 | |
| | 192 | The most common form of container specialization is the configuration format that the container expects. We have defined formats for containers that look like computers that define accounts, filesystems, software installations, etc. Other configuration formats will evolve and move into the mainstream. |
| | 193 | |
| | 194 | In addition we define low-level commands in an experiment description that bind a configuration message content to a node in an experiment. This allows new container configurations to be communicates even when the testbed does not understand them. |
| | 195 | |
| | 196 | In addition to custom configuration systems, containers can export custom operations. For example, some virtual machines support snapshotting their state. That can be useful to experimenters. Again containers can advertise operations that the testbed is unaware of and the testbed API presents a way for users to pass a request through to a container directly. |
| | 197 | |
| | 198 | |
| | 199 | == Putting It All Together == |
| 206 | | |
| 207 | | |
| 208 | | The API provides an authenticated user (see below) with several interfaces to query and modify their profile information. |
| 209 | | |
| 210 | | In the API each element of profile data is represented as a structure with the following data in it: |
| 211 | | |
| 212 | | * name of the element |
| 213 | | * type of the element |
| 214 | | * string |
| 215 | | * integer |
| 216 | | * double |
| 217 | | * binary/opaque |
| 218 | | * lists of any of the above |
| 219 | | * value(s) of the element |
| 220 | | * a flag set if the element is optional |
| 221 | | * a modification type: elements may be read/write, read-only (e.g., username) or write-only (e.g., password) |
| 222 | | * a brief description of the field, intended to be presented by a web interface or other third party program |
| 223 | | |
| 224 | | The interfaces to manipulate a profile are |
| 225 | | |
| 226 | | * '''GetProfileDescription''' |
| 227 | | * No input required |
| 228 | | * Returns a set of empty elements that this testbed understands and requires, represented as above |
| 229 | | * '''GetUserProfile''' |
| 230 | | * No input required execpt an authenticated user |
| 231 | | * Returns a populated set of elements containing the current values of the user's profile |
| 232 | | * '''SetUserProfile''' |
| 233 | | * A list of populated elements that the (authenticated) user wishes to change in the current profile |
| 234 | | * A list of the elements successfully updated, and a list of those that failed with a reason for each |
| 235 | | |
| 236 | | |
| 237 | | === Authenticating as a User === |
| 238 | | |
| 239 | | A user represnts themself to the testbed by presenting proof that they hold a public key, for example through an SSL connection. The testbed determines what operations a user can carry out based on an ABAC-encoded policy that grants rights to users and binds keys to users. A user is issued a public key periodically by DETER, but also can request a short lived temporary key at any time by authenticating against a shared password. A temporary key is useful to allow a web application or other hosted tool to act on a user's behalf. |
| 240 | | |
| | 216 | == More Information == |
| | 217 | |
| | 218 | From here, readers may be interested in the |
| | 219 | |
| | 220 | * [wiki:NewAPISpec Detailed Specification of the API] |
| | 221 | * [wiki:NewImpl Implementation plan/roadmap] |
