[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] Proposal to change committers for the XAPI Project


  • To: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • From: Dave Scott <Dave.Scott@xxxxxxxxxx>
  • Date: Mon, 2 Jun 2014 13:21:29 +0000
  • Accept-language: en-GB, en-US
  • Cc: "xen-api@xxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 02 Jun 2014 13:21:33 +0000
  • List-id: User and development list for XCP and XAPI <xen-api.lists.xen.org>
  • Thread-index: AQHPb5GDv+0p2vu05kORxWXbRdcKZZtBIK6AgAAWJwCAAAYkgIAcjXyA
  • Thread-topic: [Xen-API] Proposal to change committers for the XAPI Project

Hi,

On 15 May 2014, at 10:19, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

> On 15 May 2014, at 09:57, Lars Kurth <lars.kurth@xxxxxxx> wrote:
> 
>> All the existing committers have voted in favour. So the proposal carries. I 
>> will update the XAPI webpage 
>> http://www.xenproject.org/developers/teams/xapi.html aaccordingly
>> Lars
>> 
> 
> This isn't intended to affect the voting, but I would note that it's slightly 
> odd for an open-source project to switch its committers in such a big sweep 
> without at least some discussion about how this affects the overall project 
> direction.
> 
> It would be really nice (from my perspective as an interested outsider) to 
> see a short introduction e-mail from the new committers, and a brief outline 
> of what they have worked in the past and the areas of Xapi that they plan to 
> improve.

I’ve been working on xapi since 2006, on pretty much everything from the domain 
handling code (VM start, shutdown, migrate etc) up through the metadata 
handling to the pooling (host clustering) logic (including HA). More recently 
I’ve been helping out with the effort to split xapi into co-operating daemons 
by moving most (almost all) of the domain handling code to xenopsd and by 
removing as many of the platform dependencies as possible to make the code 
‘just work’ on unmodified Linux distros.

I’d like to help xapi improve by:

1. resolving any remaining conflicts between higher-level cloud orchestration 
layers (cloudstack, openstack) and the host clustering layer. This means 
pushing in the direction of cross-pool shared storage and better support for 
‘pools of one’.

2. making use of libxl and libvirt where we can

3. running as many of our services as ‘unikernels’ (e.g. via MirageOS) as 
possible to make the overall system more robust (e.g. by allowing individual 
kernels to be rebooted rather than taking down dom0 and therefore the host)

Cheers,
Dave
_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.