Projects carried out in academic year 2024-25 are publicly available.
The list of projects for the current academic year are the following:
CrownLabs is able to run applications using VMs or containers. This project aims at extending CrownLabs in order to allow the platform to create and manage other Kubernetes clusters, by means of technologies such as ClusterAPI and Kubevirt. This allows student to instantiate their own native Kubernetes cluster, where they have fully administrative access, which is set up by creating multiple VMs (with Kubevirt) and automatically installing the required software (e.g., K8s control plane on one node, workers on the others, the add the required components such as CNIs, etc).
This project would provide a more secure and isolate solution compared to the current "CrownLabs sandbox" that is used for this purposes.
The setup of a minimal GUI to visualize the current state of the clusters (https://github.com/Jont828/cluster-api-visualizer ) would be a nice addition to this project.
Optional feature: it would be helpful if the children Kubernetes clusters are integrated with the controller manager of the main cluster (i.e., CrownLabs) in order to provide external access to the cluster itself.
This project leverages the existing work carried out by another group of students in academic year 2024/25.
Technologies: Kubernetes, Go, Git, (Typescript, React)
Students: Michele Castellano, Joule Koffi, Daniele Bonometti; Tutor: YYY
Liqo (https://liqo.io) is an open-source project that allows to acquire resources in another cluster and give them visibility such as being local. This starts with a peering process with the "donor" cluster, and continues by selecting the namespace which needs to be offloaded on the remote cluster, in this case the namespace of the user. However, deciding whether a namespace has to be offloaded is a difficult decision, and has to be done with care.
This project aims at providing a simple solution to this problem, leveraging a new feature of Crownlabs, namely the capability for a tenant to select the physical node where a pod has to be executed. If the user selects a remote node for the execution of its pod, the "remote offloading" policy of Liqo should be automatically turned on, hence allowing the pod to be offloaded on the remote cluster.
This can be achieved by extending the proper CrownLabs controller so that it automatically offloads the namespace when a remote node is selected for the pod deployment (and remove the offloading strategy when the pod is removed). In addition, it should be evaluated whether all users have the right to offload pods on remote cluster, or this requires the explicit setting of a dedicated administrative policy (e.g., a proper field in the tenant field).
Technologies: Kubernetes, Go, Git
Students: Stefano Michelini, Pasquale Livrieri, Samuele Vianello; Tutor: Fulvio Risso
CrownLabs currently adopts a storage solution based on Rook (https://rook.io), which leverages Ceph (https://ceph.io) to dynamically provision volumes that are then exported as NFS mount points. The internal infrastructure of CrownLabs (i.e., VMs and containers) accesses these resources exclusively through the NFS protocol, with this dependency being hardcoded within the hosted platform's codebase. This represents a big limitation, as any container/VM has to be created with the support to mount NFS volumes (which is not turned on by default on modern VMs/containers), and it requires the explicit configuration at run-time of the VM/container itself, e.g., to specify which volume has to be mounted, where, and setting the proper permissions for the local user.
The objective of this project is to completely remove the use of NFS from the CrownLabs codebase and transition to a more cloud-native approach, aligned with Kubernetes best practices. In particular, the project will explore PV mirroring strategies to ensure dynamic provisioning, persistence, and data sharing without relying on explicit NFS exports. This enable the VM/container to simply mount an external volume thanks to the Kubernetes primitives (e.g., adding a PVC in the Kubernetes Deployment), hence avoiding any modification within the container itself.
Moving toward a cloud-native storage architecture will result in a more modular, flexible, and maintainable system, simplifying future evolution and extensibility of the platform.
Technologies: Kubernetes, Go, Git (Javascript, React)
Students: Chiara Mercurio, Alessio Giliberti; Tutor: Federico Cucinella
In the recent evolutions of the CrownLabs software, users are allowed to use a "persistent" VM image, which can be used to install additional software and make it persistent. However, this new image is not optimized (e.g., free unused space on disk), nor it can be used as "golden image" to create new VMs.
This project aims at providing new "golden images" starting from existing ones, which means:
enable a "disk snapshot" button in the frontend, which allows a user to tell the system to create a new golden image;
when this button is selected, the CrownLabs takes the existing image, it applies a standard set of jobs on it (e.g., removes useless files and cleans the file system; reduces the disk size; resets the network configuration) and it creates a new golden image;
it uploads the new golden image into the CrownLabs registry, which can be used to create new VMs from it.
Technologies: Kubernetes, Go, Git, Javascript, React
Students: XXX; Tutor: YYY
CrownLabs persistent VM-based instances, from the beginning, have been stored as virtual disk files onto classic file system volumes, and these volumes are based on block devices (provided by ceph.io). This adds an un-necessary level of abstraction, since VM disks can be directly stored onto block devices, which also enables RWX access mode, which also enables live migration features. Secondarily, this same kind of instances (persistent, VM-based) always possibly took a rather long time for starting up, generally depending on the size of the image.
This project aims at switching the VMs disks storage method and then investigating how can be optimized their startup time, analyzing and experimenting ways to speed it up.
Technologies: Kubernetes, KubeVirt, Go, Git
Students: Abellonio Andrea, De Blasio Lorenzo, Kostadinov Iliyan; Tutor: YYY
NOTE: very likely, the project 5b can also be completed at almost no cost for this group.
This project represents a follow-up of the previous project, as it could be carried out in a limited amount of time given the work and the experience gained in the previous project.
CrownLabs has been recently extended to support the creation of VMs starting directly from cloud images (e.g., Ubuntu Cloud Images or Fedora Cloud Images). However, the current process requires to download the image into CrownLabs, convert into a different file format, then actually start the instance. The conversion process requires time and, in many cases, it can be avoided.
This project aims at improving the CrownLabs code base in the following directions:
modify the current code in order to support the direct launching of the VM, without conversion;
detect the case in which the image is in a non-supported format; in this case, include the conversion before launching the instance.
Technologies: Kubernetes, Go, Git
Students: XXX; Tutor: YYY
NOTE: merged with project #5
CrownLabs has been recently extended to support granular resource quota, which means that each tenant can consume a maximum amount of resources per each workspace. However, resource quota account only for the number of instances, memory, and CPU, while disk space occupancy (particularly for persistent images), nor the number of GPUs, are not taken into consideration. This could represent a problem when users are allowed to create their own VM, in which disk space consumption could become significant, and when the student is using GPUs, which are a rather scarse resource.
This project aims at extending the current code base to take into account also of disk quotas and GPUs. This includes modifications in both the backend (e.g., to calculate when the current consumption increases - e.g., a new VM is started - or decreases - e.g., an existing VM is deleted), and the frontend (e.g., extending the box where the quota is set; extending the user quota management window; extending the resource status in each workspace).
Technologies: Kubernetes, Go, Git, Javascript, React
Students: Riccardo Boccia, Matteo Zanino; Tutor: Marco Miracapillo
Recently, Kubernetes has deprecated the Ingress API in favor of the newer Gateway APIs. CrownLabs used extensibely Ingress APIs, as each time a new instance (e.g., GUI VM) is created, a new ingress resource is created, which allow the user to connect, using his browser, to the VM. However, given the new API suggested by Kubernetes, and the fact that the current Ingress controller used in CrownLabs has moved to the "unsupported" state, CrownLabs should quickly move its code base to the new APIs.
This project aims at evolving the current CrownLabs codebase to Gateway API, maintaining the compatibility with current applications and services.
Technologies: Kubernetes, Go, Git
Students: Federico Farci, Paolo Galiano Bove, Alessandro Annecchini; Tutor: YYY
NOTE: given that this project appears to be small for a group of 3 people, we suggest to carry out also the project #10.
Kubernetes support serverless computing through several frameworks, such as Knative. This project aims at delivering a Proof-of-Concept for a possible (future) implementation of serverless functions in CrownLabs, determining which components have to be added, how they should be congured, and which modifications to the CrownLabs code base are required to support this function.
Technologies: Kubernetes, Knative (or alternative), Go, Git
Students: XXX; Tutor: YYY
A project in previous academic year has extended CrownLabs to support automatic cleanup of stale instances to save resource. In a nutshell, if an instance (e.g., VM) is not used for a given amount of time, it is automatically powerered off. This mitigates the problem of users (i.e., students) who start a VM for a lab, and never turn it off.
However, this mechanism has two problems:
the instance is cleared, but the disk space (e.g., for persistent VM) is still used;
the instance is powered off, hence losing the entire state. It could be better to create a snapshot, i.e., freezing the VM together with its memory, in order to be able to resume its operations without losing the state.
This project aims at extending the current CrownLabs codebase with the two above mentioned features: (1) enable the "suspend/resume" action in persistent VMs, and (2) destroy, if no longer needed (and not used anymore by the user) stale instances on disk.
Technologies: Kubernetes, Go, Git, Javascript, React
Students: Convertino Alessandro, Rosato Matteo, Valeria Moliterno; Tutor: Marco Miracapillo
When a persistent VM is stopped and then restarted, there is no guarantee that its IP address will not change. In fact, the mostly likely case is that the CNI will assign a new IP address to the pod, which is in fact seen as a "new" instance. This may have a dramatic impact on some applications running inside the VM, e.g., K3s or DevStack, which read their IP address when they are installed, and that cannot change it anymore; any change occurring to the IP address will not be detected anymore, and it requires the software to be re-installed from scratch.
This project aims at exploring the possibility to define "persistent" IP addresses, and assign always the same IP address to the VMs that require this feature. This includes exploring how this can be done given the Cilium CNI used in CrownLabs, extending the instance template to support this new feature, and extending the template window to allow users to turn this feature on/off when needed.
Technologies: Kubernetes, Go, Git, Javascript, React
Students: XXX; Tutor: YYY
NOTE: Merged with project #7
Introduce automatic vertical pod autoscaler in CrownLabs
Live migration on VM
Enable disk snapshotting, e.g., for backup.