Hi guys, Thank you for showing your interest in Ganeti. Thanks Oleg for the introductory email. I just just wanted to extend a few details:
1) The reason why we require from students to submit a patch is that they need to be familiar with both the development process and with setting up a Ganeti cluster. This requires a considerable effort and would prevent you from being productive when the actual coding should start. 2) Unfortunately Google cannot provide access for external contributors to our internal systems, you will have to set up a small test cluster on you own machines. Cheers, Viktor On Monday, March 21, 2016 at 8:10:27 PM UTC, Oleg Ponomarev wrote: > > Hi everybody, > > It's glad to hear from all of you. It seems that each of you is > experienced enough to develop for Ganeti this summer. Unfortunately, we > have a limited number of slots, so it's impossible to select everybody. The > selection process will mainly depend on your proposals. It's better to > demonstrate deep understanding of a problem in a proposal. You are welcome > to ask any questions and even discuss your own ideas but it's only 5 days > left. > > Since once in the past Ganeti has faced with negative experience working > with a GSoC student, currently* it's obligatory to have at least one > patch accepted to the mainline* in order to be selected. This requirement > is necessary to ensure that the development environment will not become a > barrier for you this summer. Please note, Ganeti is a huge project with a > lot of dependencies and even compilation of the codebase may become a > challenging task. The deadline for patch submission is April, 9th. It's > still enough time but the development and code review process may last for > a while, especially for the first patch. I suggest you to pay attention to > the issues tagged with "SmallTask". Of course, you are welcome to ask any > questions in the meantime. > > And now some comments about the projects: > 1) Optimize balancing speed by accounting for migration speed: > In this project, it's necessary to extend HTools with a new functionality. > HTools is written in Haskell (and even Template Haskell), so you should > have an acceptable Haskell knowledge. Python knowledge is necessary as well > in order to understand the codebase. > As I already commented, the main part of the task is open-ended (I mean an > estimation of move/migration time) and it might make sense to start with > some simple heuristics, then implement the necessary options and only > afterwards try some complex methods for the estimations (e.g. collect > historical data and try some time series predictions). > > I'll be a mentor of a student who'll be selected to work on this project > (if any). > > 2) Improve KVM Live Migration: > Please, don't become confused with the topic name. You don' need to > implement any migration algorithms or write hypervizor code here. If you > are interesting in hypervizor development - you are welcome to apply to > QEMU but not to Ganeti. The main idea here is to extend KVM hypervisor > support code on the Ganeti side in order to support the new migration > improvements that have been already implemented in QEMU. Hypervisor support > part of Ganeti is implemented in Python but working on Ganeti, at some > point you'll have to read and modify some bits of Haskell code anyway. > > As for this project, probably, somebody else will be your mentor. > > Good luck with your proposals! > > And do not hesitate to ask any questions. But please be specific. > Questions like "I want to write some code for Ganeti this summer. How can I > start?" are too general to answer. You already have basic information on > the ideas page. > > Thanks for your interest in Ganeti, > Oleg >
