As it is widely know, really tough Open Source users –the ones that wear sandals, colored hats of various kind, and are equipped with long enough UNIX beards— always install software via tarballs and some good old ./configure-make-make-install-fu! Then there are the developers, who couldn’t care less about installing: all that matters is from where you can checkout –well, actually, this days it’d better be git clone— the code. Once you got it, and you compile it with no errors, what else is remaining and what on Earth you want to install it for, right?
(Un?)Fortunately, there exist different kind of people too. They, whiskered or not, are usually very happy every time they can avoid dealing with either tar or git, and can start using some software by only sending a couple of directives to their favorite distribution’s package manager. That, usually, means a loot of cool things, like automatic dependency tracking, cleanup upon uninstall, smooth update to new versions, and all this kind of stuff. However, for this to work, it is required that someone has stepped up to act as the package maintainer of that particular software for the specific distribution. Package maintainers are in a very peculiar spot. In fact, wrt the software they package, they’re not regular users, nor they (not necessarily, at least) act as core developers for it, and yet they play an important role in determining the degree of success of a project.
Therefore, in seek of a better understanding, useful feedback and improved collaboration, Xen Project reached out to one of the Xen packagers for a major distributions, and asked him a bunch of questions. That happened a couple of months ago, and today we publish his answers here. As a confirmation that these package maintainers are weird chaps, this particular one says he does not take in any caffeine… Contradicting countless and repeated studies and researches conducted with geeks as guinea pigs!! Apart from that, quite a bit of really useful points and observation results from the conversation below, and we are happy to tell Maarten (and everyone else) that many of the things he suggests improving have been already or are being worked on. We also decided that his answers were so useful, that we’ll definitely continue investigating along this line, so expect more interview to Xen package maintainers in the coming weeks.
So, let’s thank Maarten Vanraes, maintainer of the Xen package for Mageia, and go straight to what he told us.
Xen-project: What’s your name, where are you from, and where do you live?
Maarten: My name is Maarten Vanraes (AL13N on Freenode) and I live in the northern (Flemish) region of Belgium (close to Brussels).
What do you do for living, and what is the distro you maintain the Xen package for?
In my dayjob, I’m a Consultant for a small IT firm based in Leuven, Belgium (http://www.ba.be/). In my spare time, I’m the maintainer of a few packages in the Mageia distro ( MariaDB and Xen are the most notable ones).
Do you (usually) spend your working hours in an office, or do you work from home?
In my dayjob i work mostly in our office, sometimes I go onsite for a client.
Where do you get your daily caffeine intake from?
I’m afraid I might be the exception to the rule here… I don’t take any caffeine 🙂
Why Mageia, and how did you get involved with it?
As so many of us, I got started using Mandrake/Mandriva and since my idea of the perfect distribution is the one that you spend the least amount of time on to get stuff done (the right tool for the right job), I felt I had to contribute back to what I had been using for years. I was already apprentice packager when Mandriva was not going well, and after the fork of Mageia, I followed my mentor at that time and so many other contributors into Mageia. In a sense I started with Mageia since Day one. Mostly due to the fact that it’s a non-profit organisation without any outside influence: a true community distribution.
Why Xen, and how did you get involved with it?
I got involved with virtualisation in my dayjob and Xen helped us get a very  efficient basis for our new datacenter at that time. As most of you know, at some point the dom0 kernels became an issue, so we turned partly to other virtualisation solutions at that time. but then the pvops kernels came into light and after some waiting time(until it was dom0 ready), I decided that it was time to get a “cleaner” setup of xen for Mageia and since it was “maintainerless” in Mageia, I stepped up and tried to go for a cleaner setup and tried to get Xen better integrated in our regular kernels, so that we wouldn’t need to have a different kernel for Xen (for both dom0 and domU).
What is it that you like most of Xen? What is it that you think is unique/distinguishing of it, wrt to other Open Source virtualization solutions?
What is it (if any! :-P) that you dislike most of it?
I’m personally of the opinion that having a separate hypervisor is one of the important aspects of Xen. if you combine this with well-supported back- and forward compatibility for the hypervisor accross kernels, and cpu-independance and live-migrations, you have a recipe for possibly eternal online-availability of your guests. This because you can just simply install a new machine with new kernel and new Xen hypervisor, move over your guests and then upgrade your older host to new kernel and hypervisor, and then the next, until all of your hosts are up 2 date. IMHO, this theoretically makes Xen architecturally the best virtualisation solution.
Some other major point for me is the efficiency… the amount of paravirtualised VMs you can have on the same hardware compared to other virtualisation solutions is amazing.
A downside is really the current integration in the Linux “plumbing”:
- qemu support (even though it’s mostly getting there, it’s not there yet) and this includes also the ability to build the Xen support from the qemu tree, and having the buildchain detect and use qemu-devel packages instead of fetching full sources. In fact this should be done for all of Xen. our Mageia buildnodes have (for good reason) no internet access and it would be better to not include any fetched or other tarballs from other projects and thus have better separation and integration.
- libvirtd support (ATM, the libvirtd support is basic to say the least) i’m pretty sure libvirtd support would benefit from some help from Xen developers. This is an important part of the future as the minimalistic nature of libxl will make for better integration in various existing and emerging tools, libvirtd based tools will make Xen more suitable in cloud-based tools and more integrated in an environment with various virtualisation solutions.
Another current downside is the current amount of security bugs. Perhaps this could be more alleviated as some review or whatnot during development time.
Do you also use Xen for work (or leisure) and, if yes, do you use Mageia and, hence, your own packages for that?
I don’t use Xen for personal use, (i believe Xen is much more suited for dedicated virtualization and KVM is more suited for additional virtualization on a desktop)
As i mentioned before, we do use Xen at work, in our datacenters. They are still old-style xenlinuxes which are gentoo-based (due to some additional kernel patching required). I think the current state of pvops kernel would be sufficient for replacement, so we are evaluating that atm. However, my boss had the impression that Xen was getting abandoned (eg by RedHat), if you guys would be used again for RedHat’s virtualisation (even if only as an alternative) that would probably be a big plus.
Do you have any, even very rough, idea of how many people uses Xen on Mageia, which of course means how many people use your package(s)?
In any Open Source project an idea of how many people use something particularly is very very hard, since there is not that much control wrt being Open Source. I do know that since i revamped our Xen packages, a few users have communicated to me about Xen. One such example is a person who wants to do virtualization on hardware which doesn’t have full virtualization support.
How is your interaction with Xen Mageia users? Do they regularly feel bug reports and/or get in touch with you in any way? If yes, what they typically say, do they have any recurrent requests or complaints?
Since the revamping takes place for our coming Mageia 3 release [which was imminent back when we interviewed xxx, Ed.], I mostly get bug reports by a limited group of people. Most of the complaints are actually related libvirtd integration issues.
How do you find the work of packaging Xen for Mageia? Do you think it is different from packaging other pieces of software, and, if yes, why?
It is different, than for example MariaDB, this is because of a few differences:
- build process: the current build process is in a standalone pov. There are parts where other sources are fetched (which is a bad practice for distributions). Distributions are about finding the best versions of each packages in order for them to work together towards the best solutions. That means the build process would be better if it was more separated from other things. qemu is a good example of this: please, don’t fetch or include the source, but have qemu build the qemu-xen stuff and link to the headers or libraries (qemu-devel packages) from qemu for whatever that is needed (if any). of course, this concept is a bit different wrt to stub dom generation… and i’m personally not sure on what the best approach is wrt to stub dom generation, except that it might (or not) work better if the versions are the same as the versions of that software that exists on the other side of the distro…
- communication towards distributions/packagers: MariaDB has for example a dedicated private mailing list towards distribution packagers, which is used for example for early warnings regarding security bugs and common packagers issues. I believe Xen’s integration in distributions would improve from such a concept. At the same time, MariaDB also communicates very openly due to the foundation’s very nature, and so i can speak with the developers quite easily on IRC on freenode. This may or may not apply to Xen, but it has gotten me very fast to the best people suited for whatever problem I had wrt the packaging. I can agree that most of the problems can be resolved at xen-devel mailing list. but some things like changing the nature on how it’s built is not something most people can help me with… it’s not like i can just decide for myself and send patches for this… plus, even though I’m a packager, i don’t know as much as a developer, there could be perhaps a good reason for this or that… at such a time, it’s helpful to have some sort of communication method to the correct people who can help me with very little of their time.
What is the most challenging aspect you face (or have ever faced)Â regarding packaging Xen?
There are some tricky parts in the Xen ecology which might not be as well explained as it could be. Or rather, there is some conflicting documentation spread around… it would be helpful to have a place with definitive central documentation for whatever versions or whatever toolsets you use (and/or explain some of the tricky parts). eg: XENBUS and how in gods’ name do the correct drivers get loaded? Is there a good and definite solution for this?
What’s your workflow like? For instance, when do you decide there is the need for a new package revision, or version? How do you handle new Xen releases, security fixes, and stuff like these?
Our distribution is not rolling (for good reason: rolling distributions will always have less QA due to the fast nature or even the sheer possibilities that cannot all be tested, and thus will inevitably at some point lack in stability).
This means that we have a few stable versions and a development version. Policies dictate that updates to stable versions should prefer not to have new features (unless no other way), simple because new features could mean new bugs/regressions, which is exactly what we’re trying to refrain from. Once a Xen version is set (ATM we are in version freeze for Mageia 3, which means we’ll have 4.2.1 there). This means that If there’s a new version, I will likely search for major and security bugs, gather patches for them, and build it like that. I usually get notified by a person following security issues, but ATM I have no clear way to follow new versions.
MariaDB project send an email to their packagers list if a release is coming (in the next day or so), giving me the time to update to their new version for our development release. In a private packager mailing list there could be notifications of coming releases and security bugs (even before those are public knowledge) so that i could prepare myself for updates.
Since you started being the Xen package maintainer for Mageia, what has been the most notable Xen development related event that affected your work, either positively or negatively… I mean has there ever been anything that shook your workflow from the very foundations?
Not really fundamental shakings, but at some point there has been quite a few security patches which meant that I told QA team to hold off, until I was sure there were no new ones.
The qemu upstream integration news made me try it that way on 4.2.1(cause it sounds like a good idea) but I gave up on that for the moment. I’m waiting until the last few stuff are upstreamed and hopefully the build process has been simplified wrt qemu integration.
How is it your interaction with the upstream Xen community? Do you usually find the help you need (if any) and, if no, what can we do for making things better?
As mentioned before, it would be easier to have a private mailing list wrt Xen distro packagers, that hopefully is followed by some developers and/or people who can direct questions to appropriate parties.
Is there something you’d ask to the Xen Dev community –something like “please do”, or “please keep on doing”, or “please stop”, or even “please never start doing”?
- please keep doing upstream integration
- please keep doing the minimalistic approach (libxl)
- please do help the libvirtd integration
AFAICT you guys are doing a good job already, if some of the suggestions I mentioned could get done, that would be awesome…
Are you a member of the Church of Emacs, or do you follow the Vim Heresy?
I’m a Heretic 🙂
For getting in touch with you, what electronic channels (mailing list, IRCs, etc.) are the relevant ones? What about in person (conferences, etc.)?
I’m pretty easy to get in touch with, i idle 24/7 on IRC on Freenode as AL13N, (I promise to backscroll and reply if you ping me) and I’m sure that in this day and age my email addresses are easily locatable for people who try to find me 🙂
As for conferences, given my location, I have been at FOSDEM the last few years at the Mageia booth.
