| 7 | | The PlanetLab project made significant changes to the software that manages the booting and initialization of PlanetLab nodes. Since the SPP relies on these mechanisms as well, we have had to make some changes to our own software to accommodate the changes made by PlanetLab. As context, when a PlanetLab node comes up, it contacts PlanetLab Central (PLC) to obtain a boot image and a variety of configuration data. Since the GPEs in an SPP run the PlanetLab OS, they also attempt to contact PLC when they boot. However, the SPP is designed to look to the external world, like a single PlanetLab node, so it would be inappropriate to let the GPEs contact PLC directly. To avoid making unnecessary changes to the GPE (which would make it difficult for us to track future changes to the PlanetLab code), we have implemented a software module running on the SPP's control processor that intercepts the connections between the GPEs and PLC, hiding the internal structure of the SPP from PLC, while still getting the GPEs the information they need to complete their initialization. We have implemented and tested the changes needed to this module to allow us to stay consistent with PlanetLab. |
| | 7 | The PlanetLab project made significant changes to the software that |
| | 8 | manages the booting and initialization of standard Linux/Vserver nodes. Since the SPP relies on these mechanisms as well, we have had to make some changes to our own software to accommodate the PlanetLab modifications. There are two core 'boot time' issues: 1) each GPE requires unique configuration information and 2) it is inappropriate for each GPE to independently report possibly contradictory node state information to the PLC. |
| | 9 | |
| | 10 | As context, when a PlanetLab node comes up, it obtains the initial boot image and node configuration information from a local read-only file system. After bringing up the interfaces it contacts PlanetLab Central (PLC) to obtain the final boot image and a variety of configuration data. Since the GPEs in an SPP run the PlanetLab OS, they follow this same procedure. However, we have had to modify the initial boot scripts to use the local control processor as a boot server thus obtaining GPE specific boot images and configuration information. |
| | 11 | |
| | 12 | Once a PlanetLab node has completed this initial boot sequence it then contacts PLC to both download node-specific information and to report it's boot state and other ancillary information. However, the SPP is designed to look to the external world, like a single PlanetLab node, so it would be inappropriate to let the GPEs contact PLC directly. For example, if one GPE boots correctly but a second fails then the node state would be set to the value last reported (the state reported should be controlled by policy). To avoid making unnecessary changes to the PlanetLab control software (which would make it difficult for us to track future changes to the PlanetLab code), we have implemented a software module running on the SPP's control processor that intercepts the connections between the GPEs and PLC, hiding the internal structure of the SPP from PLC, while while allowing us to manage the information flow between the PLC and GPEs. We have implemented and tested the changes needed to this module to allow us to stay consistent with PlanetLab. |
