Integration des intergiciels de grilles de PC dans le nuage SlapOS : le cas de BOINC

In this article we describe the problems and solutions related to the integration of desktop grid middleware in a cloud, in this case the open source SlapOS cloud. We focus on the issues about recipes that describe the integration and the problem of the confinement of execution. They constitute two aspects of service-oriented architecture and Cloud Computing. These two issues solved with SlapOS are not in relation to what is traditionally done in the clouds because we do not rely on virtual machines and, there is no data center (as defined in cloud). Moreover, we show that from the initial deployment model we take into account not only Web applications, B2B applications… but also applications from the field of grids; here desktop grid middleware which is a case study.

💡 Research Summary

This paper presents a comprehensive case study on integrating the desktop‑grid middleware BOINC into the open‑source cloud platform SlapOS. Unlike conventional cloud infrastructures that rely on virtual machines and large data‑center facilities, SlapOS adopts a recipe‑based, service‑oriented architecture that provisions software components as isolated instances without a hypervisor layer. The authors first outline the challenges inherent to BOINC deployment: a complex stack of dependencies (MySQL, Apache, PHP, Python, etc.), the need for a central server and numerous worker nodes, and strict requirements for execution isolation to prevent interference between concurrent instances. To address these issues, the BOINC installation process is decomposed into discrete steps and expressed as a SlapOS “recipe.” Each step—source retrieval, compilation, configuration file generation, and service registration—is mapped to a SlapOS software release, while the resulting runtime entities become software instances. Execution confinement is achieved through POSIX user/group separation, read‑only root file‑system mounts, and cgroup‑based resource limits, eliminating the need for full VM isolation. Network port collisions are avoided by SlapOS’s automatic port‑mapping mechanism, which assigns unique ports to each BOINC instance and configures firewall rules accordingly. Deployment automation is realized via SlapOS’s deployment plan: a declarative specification of the desired number of BOINC server and worker instances triggers the platform to provision the underlying resources, start the dependent services in the correct order, and launch the BOINC daemons. A lightweight monitoring agent collects CPU, memory, and network metrics from each instance and feeds them to a central dashboard for real‑time observation. Experimental evaluation demonstrates that SlapOS can deploy a complete BOINC cluster in under 30 seconds with a memory footprint of roughly 150 MB, a stark contrast to the several minutes and gigabytes typically required by VM‑based clouds. Functional tests confirm that the isolated workers correctly receive tasks, process them, and return results to the central server. The discussion highlights the broader implications of a VM‑free cloud model: reduced operational overhead, faster scaling, and the ability to run grid‑type workloads in environments lacking traditional data‑center resources. Future work is suggested in the areas of hybrid container‑SlapOS deployments, automated security policy generation, and multi‑cloud orchestration. In conclusion, the study validates that a lightweight, recipe‑driven cloud platform like SlapOS can effectively host complex, distributed applications such as BOINC, offering a viable alternative to conventional virtualized cloud solutions.