[GSoC] Adding emulated BMC support to KubeVirt (KubeVirtBMC)

[0xFelix]

Title: Adding emulated BMC support to KubeVirt (KubeVirtBMC)

Description

KubeVirt is a virtualization API for Kubernetes, that allows to run virtual machine-based workloads on Kubernetes. [1]

Often times, developers require the ability to deploy applications or systems in local virtual environments like bare-metal ones. Existing solutions involve libvirt domains or QEMU VMs with Baseboard Management Controller (BMC) emulators, which are not directly compatible with KubeVirt, necessitating a Kubernetes-native solution. The original RFE [2] was followed up by an implementation of a BMC emulator for KubeVirt named KubeVirtBMC [3].

KubeVirtBMC facilitates the deployment of software/applications/platforms such as OpenShift and OpenStack - whose installers typically require communication with bare-metal out-of-band management protocols like IPMI and Redfish - in KubeVirt VMs for development, testing, and debugging purposes, similar to the functionality provided by VirtualBMC [4] and sushy-emulator [5] but within a Kubernetes context.

As a result, a KubeVirt feature proposal was created and accepted [6], which now needs to be implemented. The proposal is divided into four phases, with work on phase one having already begun.

See this document for additional context [7].

Expected outcome

The project goal is to transfer KubeVirtBMC into the KubeVirt organization and to continue the development of a native BMC emulator for KubeVirt as laid out in the accepted proposal. Phases one to three of the proposal should be completed, while phase four is optional.

Project requirements

Project size: 350 hours
Difficult: Hard
Required skills: Kubernetes knowledge, GoLang programming skills, possibly experience with BMCs and the IPMI/Redfish protocols
Mentors: Felix Matouschek [email protected], Zespre Chang [email protected]

How to start

1. Learn about KubeVirt and get started by installing KubeVirt and deploying KubeVirt VMs yourself [1], [8], [9]
2. [Optional] Look for good-first issues and try to solve one to get familiar with the project [10]
3. Learn about KubeVirtBMC and its feature proposal, get it running in your own environment and play with it [3], [6]
4. Learn about protocols such as IPMI and Redfish and the associated use cases [11]
5. Try to use automation that utilizes BMCs for "bare metal" deployments
6. Try to understand the current state of the project and capture the missing pieces needed to complete the phases in the proposal [6]

How to submit the proposal

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.

What the proposal should contain

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 [12] and template [13]. However, it should contain a draft schedule of the project phases with some planned extra time to overcome eventual difficulties.

Links

[1] https://kubevirt.io
[2] kubevirt/kubevirt#9108
[3] https://github.com/starbops/kubebmc
[4] https://opendev.org/openstack/virtualbmc
[5] https://opendev.org/openstack/sushy-tools
[6] #264
[7] https://docs.google.com/document/d/13oy-jdAPJjNfl_FpUuOT6O0Sc_q8ruuaZ2e1Q_T90V0
[8] https://kubevirt.io/user-guide
[9] https://github.com/kubevirt/kubevirt/blob/main/docs/getting-started.md
[10] https://github.com/kubevirt/kubevirt/issues?q=is%3Aissue%20state%3Aopen%20label%3Agood-first-issue
[11] https://www.dmtf.org/standards/redfish
[12] https://github.com/kubevirt/community/tree/main/design-proposals
[13] https://github.com/kubevirt/community/blob/main/design-proposals/proposal-template.md

[0xFelix]

/cc @aburdenthehand @starbops

[ahmadateya]

This project is exciting for me! I’m currently working on drafting my document. Would it be possible to start discussions and request reviews now, or should I wait until the official announcement on February 27th to align with the schedule? Either way, I’m interested in contributing to this project beyond GSoC. Are contributions to kubevirtbmc currently being accepted?

[0xFelix]

Please wait until the official announcement.

Contributions to KubeVirtBMC are of course welcome, but should not contradict the GSoC project.