Google Summer of Code 2016

From Libvirt Wiki
Revision as of 09:00, 22 February 2016 by Marty (talk | contribs) (Added node bindings idea)
Jump to: navigation, search

Google Summer of Code 2016

Introduction

Like in the previous years, libvirt is willing to apply for Google Summer of Code 2016. This page serves to collect ideas and informations for both students and mentors. But this year we have decided to try applying as a separate organization, because the number of libvirt applicants simply grew higher than qemu or kvm combined. So it wouldn't be fair if we continued outsourcing program management onto qemu project. Hopefully, this has no effect on students nor mentors.

NOTE: The mentoring organizations have NOT been chosen yet, so please take this list as non guaranteed yet.

Process

Firstly, there were some important changes in rules. Be sure to read them first. On the top of those we have some additional guidelines as follows.

Each student can sign up for as many ideas listed here as they want. With each candidate respective mentor will do an interview (usually through IRC) consisting of a coding exercise and some follow up questions to evaluate their ability to code. Some examples of exercises from previous years can be found here.

Additional information

This page is meant to extend qemu page dedicated to GSoC: [1].

Contacts

  • IRC (GSoC specific): #qemu-gsoc on irc.oftc.net
  • IRC (development and general): #virt on irc.oftc.net
  • libvir-list

Please contact the respective mentor for the idea you are interested in. For general questions feel free to contact me: Michal Prívozník (IRC nick: mprivozn).

Project ideas

Here is the list of libvirt ideas. If an idea involving work in both libvirt and qemu appears it should be listed here and on qemu list too.

Introducing job control to the storage driver

Summary: Currently, libvirt support job cancellation and progress reporting on domains. That is, if there's a long running job on a domain, e.g. migration, libvirt reports how much data has already been transferred to the destination and how much still needs to be transferred. However, libvirt lacks such information reporting in storage area, to which libvirt developers refer to as the storage driver. The aim is to report progress on several storage tasks, like volume wiping, file allocation an others.

  • Component: libvirt
  • Skill level: intermediate
  • Language: C
  • Mentor: Michal Privoznik <mprivozn@redhat.com>, mprivozn on IRC (#virt OFTC)
  • Suggested by: Michal Privoznik <mprivozn@redhat.com>

Making virsh more bash like

Summary: If you have ever used virsh, you certainly reached the point where you stuggle with its user friendliness. Or unfriendliness I should rather say. Virsh is missing a lot of bash functionality that users consider natural: from automatic completion of object names, through redirecting command outputs through piping commands together. The aim would be to make these functions available in virsh and thus make user experience better.

  • Component: libvirt
  • Skill level: Advanced
  • Language: C
  • Mentor: Michal Privoznik <mprivozn@redhat.com>, mprivozn on IRC (#virt OFTC)
  • Suggested by: Michal Privoznik <mprivozn@redhat.com>

Abstracting device address allocation

Summary: There are many types of addresses that devices can have in libvirt's XML description. Not all address types are properly assigned and checked for duplicates. The goal of this is to have an abstract data structure that would handle assigning all kinds of addresses, handle duplicates, etc.

  • Component: libvirt
  • Skill level: beginner
  • Language: C
  • Mentor: Martin Kletzander <mkletzan@redhat.com>
  • Suggested by: Martin Kletzander <mkletzan@redhat.com>

libvirt bindings for node.js

Summary: There are few libvirt bindings for node.js available via npm. However none of them expose all libvirt APIs. That is mainly because they are manually written and not automatically generated. The aim is to utilize same information that python bindings do and automatically generate node libvirt bindings based on that information so that they don't need to be modified for every new API.

  • Component: libvirt
  • Skill level: advanced
  • Language: C, C++, node-gyp, scripting language of your choice
  • Mentor: Martin Kletzander <mkletzan@redhat.com>
  • Suggested by: Martin Kletzander <mkletzan@redhat.com>

Links:

QEMU command line generator XML fuzzing

Summary: Using fuzzing techniques to generate unusual XML to feed to QEMU command line generator

There are a huge number of potential variants of XML documents that can be fed into libvirt. Only a subset of these are valid for generating QEMU command lines. It is likely that there are cases where omitting certain attributes or XML elements will cause the QEMU command line generator to crash. Using fuzzing techniques to generate unusual XML documents which could then be fed through the test suite may identify crashes.

Details:

  • Component: libvirt
  • Skill level: intermediate
  • Language: C
  • Mentor: Martin Kletzander <mkletzan@redhat.com>
  • Suggested by: Daniel Berrange

Asynchronous lifecycle events for storage objects

Summary: Implement asynchronous lifecycle events for libvirt's storage APIs. Lifecycle events allow apps to get notifications about object creation, deletion, and state change with out having to poll libvirt at regular intervals.

There are already lifecycle event APIs for domains/VMs and network objects, and generic infrastructure handling a lot of the heavy lifting, so there's plenty of examples to follow to implement much of this.

Time permitting, there's lots of additional work that can be done:

  • Add support for these events in virt-manager UI tool. In fact this is probably the best way to actually test the APIs
  • Extend libvirt (and virt-manager) with async events support for nodedev objects (physical host devices). This will likely be a simple task after the storage APIs are added.
  • Investigate adding event support for interface objects (host network devices). Implementing this for libvirt's udev driver is probably straightforward, but the netcf driver may be more complicated.

Links:

Details:

  • Skill level: intermediate
  • Language: C, python
  • Mentor: Cole Robinson <crobinso@redhat.com>
  • Suggested by: Cole Robinson <crobinso@redhat.com>

Conversion to and from OCI-formatted containers

Summary: Container formats is being standardized by Open Container Initiative. libvirt-lxc support for them would be awesome.

virsh has domxml-from-native and domxml-to-native to help converting between libvirt configuration and another one. In the libvirt-lxc driver the domxml-from-native command already supports converting from lxc (yes, naming is confusing). The goal is not only to implement it also for OCI format but also to implement export to OCI format.

Some code pointers to get started:

Note that there may be tricky things to handle, like disk images conversion to a rootfs, but this project aims at implementing the simple cases first. If time permits, the corner cases could be handled as well.

Details:

  • Component: libvirt
  • Skill level: intermediate
  • Language: C
  • Mentor: Cédric Bosdonnat <cbosdonnat@suse.com>
  • Suggested by: Cédric Bosdonnat

Template

=== TITLE ===
 
 '''Summary:''' Short description of the project
 
 Detailed description of the project.
 
 '''Links:'''
 * Wiki links to relevant material
 * External links to mailing lists or web sites
 
 '''Details:'''
 * Skill level: beginner or intermediate or advanced
 * Language: C
 * Mentor: Email address and IRC nick
 * Suggested by: Person who suggested the idea