Difference between revisions of "Google Summer of Code 2017"

From Libvirt Wiki
Jump to: navigation, search
m (Add __attribute__((cleanup)) idea)
(This page now lists only accepted projects.)
Line 1: Line 1:
http://opensource.googleblog.com/2016/10/announcing-google-code-in-2016-and.html
 
 
= Google Summer of Code 2017 =
 
= Google Summer of Code 2017 =
  
 
== Introduction ==
 
== Introduction ==
Like in the previous years, libvirt is willing to apply for [http://g.co/gsoc Google Summer of Code 2017]. The program has been just [http://opensource.googleblog.com/2016/10/announcing-google-code-in-2016-and.html announced]. This page serves to collect ideas and informations for both students and mentors.
+
Like in the previous years, libvirt is willing to apply for [http://g.co/gsoc Google Summer of Code 2017]. The program has been just [http://opensource.googleblog.com/2016/10/announcing-google-code-in-2016-and.html announced]. This page lists accepted projects only. For the list of ideas go [[Google_Summer_of_Code_Ideas | here]].
  
 
== Contacts ==
 
== Contacts ==
Line 12: Line 11:
 
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).
 
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 ==
+
== Timeline ==
  
Here is the list of libvirt ideas.
+
The timeline is to be found [https://developers.google.com/open-source/gsoc/timeline here].
  
=== Introducing job control to the storage driver ===
+
== Project ideas ==
 
 
'''Summary:''' Implement abstract job control and use it to improve storage driver.
 
 
 
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: advanced
 
* Language: C
 
* Mentor: Pavel Hrdina <phrdina@redhat.com>, phrdina on IRC (#virt OFTC)
 
* Suggested by: Michal Privoznik <mprivozn@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:'''
 
* node-gyp: https://github.com/nodejs/node-gyp
 
 
 
=== 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:
 
* Suggested by: Daniel Berrange
 
 
 
=== Conversion to and from OCI-formatted containers ===
 
 
'''Summary:''' Container formats is being standardized by [https://www.opencontainers.org 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 [https://linuxcontainers.org/ lxc] (yes, naming is confusing). The goal is not only to implement it also for [https://github.com/opencontainers/specs OCI format] but also to implement export to OCI format.
 
 
 
Some code pointers to get started:
 
* [http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/lxc/lxc_native.c src/lxc/lxc_native.c] is the place where the lxc import is implemented.
 
* The starting point in the lxc driver is the [http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/lxc/lxc_driver.c#l5815 connectDomainXMLFromNative] function pointer.
 
* To add export capabilities, the [http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/driver-hypervisor.h#l282 connectDomainXMLToNative] will have to be defined.
 
 
 
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
 
 
 
=== Introduce libiscsi pool ===
 
 
'''Summary:''' Currently there is an iSCSI storage pool in libvirt. However, all the management communication is done by spawning iscsiadm binary. The aim of this project would be to rework the storage driver backend so that is uses libiscsi directly.
 
 
Libvirt has many drivers to address various parts of virtualization infrastructure. For example, it has so called domain driver which is responsible for managing virtual machines, network driver for providing connectivity to virtual machines and it has storage driver for managing storage pools and volumes. The enumeration is not complete, of course. The aim of the storage driver is to provide units of storage to virtual machines. In order to achieve that goal, the storage driver offers several APIs for management applications to use, e.g. creating a pool of volumes, creating a single volume within that pool and so on. Because of the nature of storage world, the driver has many backends which implement the APIs based on underlying storage technology used. Thus there's an LVM backend for managing LVs, FS backend for working with files and directories, and there's iSCSI backend too. This backend, however, uses iscsiadm binary to execute the desired operation. The binary can be spawned multiple times during single execution of an API. This is suboptimal esp. if there exists a better solution - libiscsi. This should be 1:1 replacement, but that's only an uneducated guess. Student working on this project should explore the possibilities of doing the replacement and implement it as well.
 
 
'''Links:'''
 
* http://libvirt.org/storage.html
 
* https://github.com/sahlberg/libiscsi
 
 
'''Details:'''
 
* Skill level: intermediate
 
* Language: C
 
* Mentor: Pavel Hrdina <phrdina@redhat.com>
 
* Suggested by: Jiri Denemark <jdenemar@redhat.com>
 
 
 
=== Enhancing libvirt-designer ===
 
 
 
'''Summary:''' The project is in its very early stage of life. The libvirt-designer tries to ease generation of libvirt XML with coworking with libosinfo project. See https://www.redhat.com/archives/libvir-list/2012-September/msg00325.html for a more detailed description.
 
 
 
During Summer of Code 2015, new API was added to make it possible to configure more VM details. This project would be a follow-up on that work, this could be :
 
* switch GNOME Boxes to using libvirt-designer instead of its own code when creating a VM. This involves work in Vala for the Boxes side, and in C on the libvirt-designer side
 
* improve libvirt-designer to make it appropriate for use by virt-manager/virt-install (written in Python)
 
* work on both libvirt-designer and libvirt-builder, with the aim of creating a command-line tool to automatically create and install a VM (through libosinfo).
 
 
 
Contact me and we can refine these potential tasks and find something suitable.
 
 
 
'''Details:'''
 
* Skill level: beginner
 
* Language: C, (potentially Python, Vala)
 
* Mentor: Christophe Fergeau <cfergeau@redhat.com>, teuf on IRC (#qemu-gsoc OFTC)
 
* Suggested by: Christophe Fergeau <cfergeau@redhat.com>
 
 
 
=== Test driver API coverage ===
 
 
'''Summary:''' Expand API coverage in the test driver
 
 
The test driver (as accessed via the test:/// URI scheme) is a fake virt driver designed to let applications test against libvirt with fake data and not have any effect on the  host. As can be seen from the API coverage report http://libvirt.org/hvsupport.html there are quite a few APIs not yet implemented in the test driver. Ideally the test driver would have 100% API coverage, and so the goal of the project is to address gaps in the API coverage. The work is incremental, so does not matter if not all APIs are implemented as part of the project - any amount of expanded coverage is sufficient and useful.
 
 
'''Links:'''
 
* API coverage http://libvirt.org/hvsupport.html
 
* Test driver http://libvirt.org/drvtest.html
 
 
'''Details:'''
 
* Skill level: beginner
 
* Language: C
 
* Suggested by: Daniel Berrange
 
 
 
=== Integrate secrets driver with <s>DEO</s> Tang/Clevis ===
 
 
'''Summary:''' Provide encryption of secrets stored by libvirt, optionally using <s>DEO</s> Tang/Clevis to unlock the master key
 
 
The libvirt secrets driver currently stores secrets in base64 plain text files with the recommendation that the filesystem be backed by a LUKS encrypted block volume. This provides protection against offline compromise, but is far from ideal. Libvirt should have its own master AES key that it uses to encrypt the individual secrets files, instead of storing them in base64.
 
 
 
Of course there is a chicken & egg problem of how to store the master AES key itself. For this we should have the ability to integrate with <s>DEO</s> Tang/Clevis to allow the master key to be password protected on local node, having <s>DEO</s> Tang/Clevis decrypt it at libvirtd startup.
 
 
'''Links:'''
 
* https://blog-ftweedal.rhcloud.com/2016/02/introduction-to-tang-and-clevis/
 
* https://github.com/npmccallum/clevis
 
* https://github.com/npmccallum/tang
 
* <s>https://blog-ftweedal.rhcloud.com/2015/09/automatic-decryption-of-tls-private-keys-with-deo/</s>
 
* <s>https://github.com/npmccallum/deo</s>
 
 
'''Details:'''
 
* Skill level: intermediate
 
* Language: C
 
* Mentor: Email address and IRC nick
 
* Suggested by: Daniel Berrange
 
 
 
=== Automatic freeing of memory ===
 
 
 
'''Summary:''' Implement <code>__attribute__((cleanup))</code> for libvirt.
 
 
 
Both gcc and clang implement the <code>__attribute__((cleanup))</code> which
 
triggers give function call whenever variable marked with this attribute goes
 
out of the scope. This can be used to automatically free the memory as soon as
 
the variable is no longer needed and thus prevent some types of memory leaks.
 
  
This attribute is used by plenty of other projects.
+
The list of project ideas can be found [[Google_Summer_of_Code_Ideas | here]].
  
'''Links:'''
+
== Accepted projects ==
* https://www.redhat.com/archives/libvir-list/2017-January/msg00323.html
 
  
'''Details:'''
+
The list of accepted projects (with student assigned) should ho here.
* Skill level: beginner
 
* Language: C
 
* Mentor: TBA
 
* Suggested by: Daniel Berrange
 
  
 
== Template ==
 
== Template ==
Line 182: Line 37:
 
  * Skill level: beginner or intermediate or advanced
 
  * Skill level: beginner or intermediate or advanced
 
  * Language: C
 
  * Language: C
  * Mentor: Email address and IRC nick
+
  * Student: Name and email address
 +
* Mentors: Email address and IRC nick
 
  * Suggested by: Person who suggested the idea</nowiki>
 
  * Suggested by: Person who suggested the idea</nowiki>

Revision as of 13:17, 16 January 2017

Google Summer of Code 2017

Introduction

Like in the previous years, libvirt is willing to apply for Google Summer of Code 2017. The program has been just announced. This page lists accepted projects only. For the list of ideas go here.

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).

Timeline

The timeline is to be found here.

Project ideas

The list of project ideas can be found here.

Accepted projects

The list of accepted projects (with student assigned) should ho here.

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
 * Student: Name and email address
 * Mentors: Email address and IRC nick
 * Suggested by: Person who suggested the idea