-
Notifications
You must be signed in to change notification settings - Fork 105
Google Summer of Code 2024
"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 21: List of accepted organizations announced
Feb 22 - Mar 18: Potential contributors discuss project application ideas with organizations
Apr 2: Contributor application deadline
May 1 - 26: Community Bonding Period
May 27 - Aug 26: 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/254
Description
KubeVirt is a Kubernetes extension to deploy Virtual Machines like pods and integrate with the Kubernetes ecosystem.
For handling host devices, KubeVirt depends on the Kubernetes device plugin framework. It is used for scheduling, allocating, and attaching a desired device and resources to a running pod.
One of the limitations of this framework is the persistence of the device allocation when the pod isn’t running. This becomes especially problematic for devices that require a significant initialization time, such as FPGAs, or storage devices, such as NVMes or USD devices, where users may have saved data. Devices assigned to the same resource name might be randomly allocated without the possibility to identify a specific device within the set.
For KubeVirt, the device is released upon shutdown or restarting of the VM due to the deletion or recreation of the VM pod. Hence, when the VM is restarted it might get a different device assigned than the previous one.
Dynamic Resource Allocation API provides a solution by introducing resource claims. The claims are independent from the pod lifetime, and they persist until the user deletes them. In this way, we are able to recognize the device that was previously assigned to a VM and preserve its state upon restarts.
Expected outcomes
The project goal is to design, develop and integrate Resource Claims in KubeVirt for host device allocation. As it is the case with PVCs nowadays, the user should be able to declare and assign a resource claim and/or template to a KubeVirt virtual machine.
To support this new Kubernetes API, the project must research and suggest ways to expand KubeVirt.
A successful project will implement a POC for an example device that is already available in Kubevirt infrastructure. The outcome of this project will provide a base for future integration of DRA, once the API reaches maturity.
Project requirements
Project size: 350 hours (Large)
Difficulty: Hard
Required skills: Kubernetes knowledge and GoLang programming skills
Desirable skills: Virtualization
Mentors: Alice Frosi afrosi@redhat.com, Victor Toso de Carvalho vtosodec@redhat.com, Luboslav Pivarc lpivarc@redhat.com
See the GitHub issue for more information on the project, how to get started, and to ask questions.
GitHub issue: https://github.com/kubevirt/community/issues/256
Description
Kubevirt boasts several innovative features, with Container Disk and Hotplug of Persistent Volume Claims (PVC) standing out among them. Both functionalities essentially involve finding a disk on the host, binding it to the running Pod, and subsequently to a Virtual Machine. However, the current implementation of these features lacks code uniformity, posing challenges to project maintainability and increasing the likelihood of similar bugs requiring distinct patches.
Expected outcomes
The primary objective of this project is to streamline and unify the implementation of Container Disk and Hotplug features within Kubevirt. By establishing a common interface for interacting with the underlying filesystem, we aim to significantly reduce and simplify the existing codebase.
The successful unification of Container Disk and Hotplug features will not only result in a more maintainable and streamlined codebase but will also contribute to making KubeVirt more cohesive and efficient.
Project requirements
Project size: 175 hours (Medium)
Difficulty: Intermediate
Required skills: Kubernetes knowledge and GoLang programming skills
Desirable skills: KubeVirt
Mentors: Antonio Cardace acardace@redhat.com, Luboslav Pivarc <lpivarc@redhat.comlpivarc@redhat.com>
See the GitHub issue for more information on the project, expanded scope and timeline, and to ask questions.
GitHub issue: https://github.com/kubevirt/community/issues/257
Description
KubevirtCI is core project of Kubevirt that allow us to provision ephemeral clusters for our CI. There are 2 types clusters that we usually need and can be provisioned, a VM based cluster or a Kind cluster. These differ because a VM cluster needs a a pre-provisioned VM images that contain everything needed to launch Kubernetes cluster within the VM. The provisioned image is split to 2 parts, a base OS image which is then enhanced by relevant Kubernetes binaries. Each Kubernetes version will therefore have a new unique image.
Expected outcomes
The goal of this project is to allow easy provisioning of the base image and to build a specific Kubernetes versions on top of it. The current project KubevirtCI can be used for inspiration but the result of this project should be a library/framework written in the Go language. It should allow us to carry less duplicates between each Kubernetes versions and allow for wider contributions than a bash-based project.
Project requirements
Project size: 350 hours (Large)
Difficulty: Intermediate
Required skills: GoLang programming, bash, and scripting skills
Desirable skills: Virtualization
Mentors: Luboslav Pivarc lpivarc@redhat.com, Antonio Cardace acardace@redhat.com
See the GitHub issue for more information on the project, how to get started, and to ask questions.
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.