134 | | In order to support experiments that are making minimal use of experiment control systems, the API allows a user to manipulate a realized experiment, including |
135 | | |
136 | | * viewing topology and state of containers |
137 | | * low-level operations on containers (start, shutdown, reconfigure) |
138 | | |
139 | | These interfaces use filtering and graph analysis to present useful views of large experiments. |
| 135 | |
| 136 | === Libraries === |
| 137 | |
| 138 | A library is a group of related experiments analogous to a circle or project being a group of related users. Libraries make relationships between experiments explicit so that users can operate on related experiments easily. As with users, projects, and experiments, libraries have profiles attached that store human-readable metadata about their contents. |
| 139 | |
| 140 | Libraries allow researchers and testbed administrators to group similar experiments and make them easy to find. For example, a library of experiments for new testbed users can be maintained by testbed administrators. A library of experiments for new members of a class or a research group can be maintained by the instructor or principal investigator. |
| 141 | |
| 142 | Access to libraries is controlled using circles as above, so once created, administration of a library can be flexible. Different libraries will have different policies. |
| 143 | |
| 144 | As with experiments, the names of libraries are unique and scoped by a user or project name. Only users delegated the explicit permission to create a library in the project name space may do so. Project owners and managers may use this permission to vet libraries. |
| 145 | |
| 146 | === Realizations === |
| 147 | |
| 148 | A realization of an experiment is a binding of experiment description to [wiki:NewAPI#Resources resources] - it is an experiment in progress. Realizations are made in the context of a circle that determines which researchers can manipulate the realization's resources. Members of that circle can log into computers, manipulate the orchestration tools, etc. |
| 149 | |
| 150 | Realizations are explicit objects because an experiment may be in progress more than once and used by different groups of researchers. |
| 151 | |
| 152 | The realization API is primarily concerned with constructing an experiment's environment by calling out through the Containers SPI |
| 153 | |
| 154 | We call the process of constructing the experiment's environment ''realizing'' the experiment. |
142 | | |
143 | | === Libraries === |
144 | | |
145 | | A library is a group of related experiments analogous to a circle or project being a group of related users. Libraries make relationships between experiments explicit so that users can operate on related experiments easily. As with users, projects, and experiments, libraries have profiles attached that store human-readable metadata about their contents. |
146 | | |
147 | | Libraries allow researchers and testbed administrators to group similar experiments and make them easy to find. For example, a library of experiments for new testbed users can be maintained by testbed administrators. A library of experiments for new members of a class or a research group can be maintained by the instructor or principal investigator. |
148 | | |
149 | | Access to libraries is controlled using circles as above, so once created, administration of a library can be flexible. Different libraries will have different policies. |
150 | | |
151 | | As with experiments, the names of libraries are unique and scoped by a user or project name. Only users delegated the explicit permission to create a library in the project name space may do so. Project owners and managers may use this permission to vet libraries. |