-
Notifications
You must be signed in to change notification settings - Fork 109
Google Summer of Code 2025
"Google Summer of Code (GSoC) is a global, online program that brings new contributors into open source software organizations." - Google Summer of Code Contributor Guide
The KubeVirt community is applying to be a Google Summer of Code organization, to provide mentorship opportunity to applicants interested in learning about open source software development in the cloud native ecosystem.
See the Google Summer of Code website for more information about the program.
Feb 27: List of accepted organizations announced
Feb 27 - Mar 24: Potential contributors discuss project application ideas with organizations
Apr 8: Contributor application deadline
May 8 - June 1: Community Bonding Period
June 2 - Sep 1: The Summer of Code!
See the Google Summer of Code timeline for more detailed timeline information.
KubeVirt is proposing the following project ideas as starting points for GSoC contributors to develop their own project applications.
GitHub issue: https://github.com/kubevirt/community/issues/384
Description
Direct directory sharing between a virtual machine and the host is made possible by filesystem devices. Pods and virtual machines can share the same Persistent Volume Claim thanks to this virtiofs. For instance, the capability to hotplugging an extra directory might be utilized to obtain diagnostic information from the VM and thereafter examine it.
While attaching a disk to a running virtual machine dynamically is standard for VMs, it is an uncommon operation for pods. KubeVirt has already implemented the capability for hotplugging disks and LUNs, but it does not yet have the functionality to add or remove filesystems from a virtual machine. The volume hotplug/unplug feature isn’t supported natively by Kubernetes. KubeVirt mechanism relies on an additional pod known as the attachment pod to schedule and attach storage to the specific node where the VM is operating. Then, the storage is hotplug through Libvirt api.
In addition, virtiofs is deployed in a separate container which is usually started together with the pod. However, in the case of hotplug, the pod cannot be dynamically modified with extra containers. This is a further challenge which needs to be taken into account during the design proposal.
Expected outcomes
The project goal is to propose and develop a solution based on the current approach of the attachment pod which supports filesystem volume types.
Project requirements
Project size: 350 hours
Difficult: Hard
Required skills: Kubernetes knowledge and GoLang programming skills
Mentors: Alice Frosi: afrosi@redhat.com, German Maglione: gmaglion@redhat.com
See the GitHub issue for more information on the project, how to get started, and to ask questions.
GitHub issue:
Description
Expected outcomes
Project requirements
GitHub issue:
Description
Expected outcomes
Project requirements
GitHub issue:
Description
Expected outcomes
Project requirements
You can submit your own project idea by emailing the kubevirt-dev Google Group and CC'ing Andrew Burden aburden@redhat.com.
If a mentor from the KubeVirt community supports the proposed project idea, we can add it to the KubeVirt project ideas list.
First, try to check KubeVirt documentation, we cover many topics and you might already find some of the answers. If there is something unclear, feel free to open an issue and a PR. This is already a great start to getting in touch with the process.
For questions related to KubeVirt and not strictly to the GSoc program, try to use the #kubevirt-dev Slack channel in the Kubernetes workspace and GitHub issues as much as possible. Your question can be useful for other people, and the mentors might have a limited amount of time. It is also important to interact with the community as much as possible.
You can also search the Slack channel archive to see if others have previously encountered the same issue.
If something doesn't work, try to document the steps and how to reproduce the issue as clearly as possible. The more information you provide, the easiest is for us to help you. If you open an issue in KubeVirt, this already guides you with a template with the kind of information we generally need.
- Install KubeVirt and deploy KubeVirt VMs following the getting started guide
- Look for good-first issues and try to solve one to get familiar with the project (if there isn’t a PR linked to it, feel free to pick it)
- Read through our General contributing guide and our Developer contributing guide for understanding of community expectations and further tips on how to get started with the project.
The preferred way is to create a google doc and share it with the mentors (slack or email work). If for any reason, google doc doesn't work for you, please share your proposal by email. Early submissions have higher chances as they will be reviewed on multiple iterations and can be further improved.
The design and your strategy for solving the challenge should be concisely explained in the proposal. Which components you anticipate touching and an example of an API are good starting points. The updates or APIs are merely a draft of what the candidate hopes to expand and change rather than being final. The details and possible issues can be discussed during the project with the mentors that can help to refine the proposal.
It is not necessary to provide an introduction to Kubernetes or KubeVirt; instead, candidates should demonstrate their familiarity with KubeVirt by describing in detail how they intend to approach the task.
Mentors may find it helpful to have a schematic drawing of the flows and examples to better grasp the solution. They will select a couple of good proposals at the end of the selection period and this will be followed by an interview with the candidate.
The proposal can have a free form or you can get inspired by the KubeVirt design proposals and template. However, it should contain a draft schedule of the project phases with some planned extra time to overcome eventual difficulties.