Overview
Comment: | Streamline the description of the example experiment. |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
40fd3082f70ed2750a2b0e66223b8b1a |
User & Date: | ivan on 2012-09-19 19:30:18 |
Other Links: | manifest | tags |
Context
2012-09-19
| ||
19:36 | Make some listings easier to read. check-in: a978492335 user: ivan tags: trunk | |
19:30 | Streamline the description of the example experiment. check-in: 40fd3082f7 user: ivan tags: trunk | |
19:09 | More attractive (and shorter) ending, with links. check-in: 012bb105e1 user: ivan tags: trunk | |
Changes
Modified script.txt from [795c276e2e] to [b01cee411c].
156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 |
Finally, the server and nodes publish management information through an API that can be used to study the testbed itself or to implement external services (like node monitoring and selection). ** An example experiment # Event diagram, hover over components explained. To show how the testbed works: two slivers, one of them (source sliver) pings the other one (target sliver). 1. The researcher first contacts the server and creates a slice description which specifies a template for slivers (e.g. Debian Squeeze i386). Experiment data is attached including a program to setup the experiment and another one to run it. 2. The server updates the registry which holds all definitions of testbed, nodes, users, slices, slivers, etc. 3. The researcher chooses a couple of nodes and creates sliver descriptions for them belonging to the previous slice. Both sliver descriptions include a public interface to the CN and user-defined properties for telling apart the source sliver from the target one. Sliver descriptions go to the registry. 4. Each of the previous nodes gets a sliver description for it. If enough resources are available, a container is created by applying the desired configuration over the selected template. 5. Once the researcher knows that slivers have been instantiated, the server can be commanded to activate the slice. The server updates the registry. 6. When nodes get instructions to activate slivers they start the containers. 7. Containers run the experiment setup program and the run program. The programs query sliver properties to decide their behaviour. 8. Researchers interact straight with containers if needed (e.g. via SSH) and collect results from them. 9. When finished, the researcher tells the server to deactivate and deinstantiate the slice. 10. Nodes get the instructions and they stop and remove containers. * Cooperation between community networks and Community-Lab |
| | | | | | | | | < | | | |
156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 |
Finally, the server and nodes publish management information through an API that can be used to study the testbed itself or to implement external services (like node monitoring and selection). ** An example experiment # Event diagram, hover over components explained. To show how the testbed works: two slivers, one of them pings the other one. Let's call them the source and target sliver, respectively. 1. The researcher first contacts the server and creates a slice description which specifies a template for slivers (e.g. Debian Squeeze i386). The researcher attaches experiment data including a program to setup slivers for the experiments and another one to run them. 2. This and all subsequent changes initiated by the researcher are stored in the registry, which holds the config of all components in the testbed. 3. The researcher chooses a couple of nodes and creates sliver descriptions for them belonging to the previous slice. Both sliver descriptions include a public interface to the CN and user-defined properties to mark slivers as either source or target. 4. Each of the previous nodes gets a sliver description for it. If enough resources are available, a container is created by applying the desired configuration over the selected template. 5. Once the researcher knows that slivers have been instantiated, the server can be commanded to activate the slice. 6. When nodes get instructions to activate slivers they start the containers. 7. Containers execute the experiment's setup and run programs. The programs query sliver properties to decide whether to act as source or target. 8. Researchers interact straight with containers if needed (e.g. via SSH) and collect results from them. 9. When finished, the researcher tells the server to deactivate and deinstantiate the slice. 10. Nodes get the instructions and they stop and remove containers. * Cooperation between community networks and Community-Lab |