Re: [Xen-devel] Xen 4.3 development update -- RC3 willo be an actual candidate, please test

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, May 30, 2013 at 5:16 PM, George Dunlap
<George.Dunlap@xxxxxxxxxxxxx> wrote:
> Things are looking in pretty good shape -- at the moment there is only
> one worrying bug on our bug tracker for which we don't have a plan.
> We're scheduled to do RC3 next Tuesday for the test day on Wednesday.
> If that test day goes well, we may actually end up releasing RC3.
>
> So if you've been waiting until the release is more stable to test,
> now is the time!
>
> Also, if you're a developer and have outstanding patches that you
> think need to be in the release, please push to try to make sure they
> are committed by end-of-day Friday (as defined by the committer who
> needs to check your patch), so we can get them through the test system
> in time for the RC on Tuesday.
>
> This information will be mirrored on the Xen 4.3 Roadmap wiki page:
>  http://wiki.xen.org/wiki/Xen_Roadmap/4.3
>
> The key goals we're focusing on now, in order, are as follows:
>  1. Have a bug-free 4.3 release
>  2. Have an awesome 4.3 release
>  3. Have a 4.3 release that happens on schedule (ready by June 15th)
>
> The most important thing in making a case is to answer the question,
> "If there are bugs in this patch, will they be discovered before the
> June 17th release?"  The second most important thing is to consider the
> cost/benefit analysis of bugs that are found: what is the risk of
> introducing a bug which will delay the release, vs the benefit it will
> have in making the release better?
>
> = Timeline =
>
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature freeze: 25 March 2013
> * Code freezing point: 15 April 2013
> * First RC: 6 May 2013 <== WE ARE HERE
> * Release: 17 June 2013
>
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  Each new feature will be
> considered on a case-by-case basis.
>
> The June 17th release is both an estimate and a goal.  At this point,
> Xen 4.3 can be released whenever it's actually ready.  In fact, the
> sooner we release, the sooner we can open the tree up for new
> development and get on to 4.4 -- so keep fixing those bugs!
>
> Last updated: 30 May 2013
>
> == Completed ==
>
> * Default to QEMU upstream (partial)
>  - pci pass-thru (external)
>  - enable dirtybit tracking during migration (external)
>  - xl cd-{insert,eject} (external)
>
> * openvswitch toostack integration
>   To label "tech-preview" unless we get good testing (>10 individuals)
>
> * NUMA scheduler affinity
>
> * Install into /usr/local by default
>
> * Allow config file to specify multiple usb devices for HVM domains
>
> * Persistent grants for blk (external)
>  - Linux
>  - qemu
>
> * Allow XSM to override IS_PRIV checks in the hypervisor
>
> * vTPM updates
>
> * Scalability: 16TiB of RAM
>
> * CPUID-based idle (don't rely on ACPI info f/ dom0)
>
> * Serial console improvements
>   -EHCI debug port
>
> == Bugs resolved since last update ==
>
> * Windows 2003 fails to install in Xen-unstable tip (RTC issues)
>   resolution: fixed
>
> * XSA-46 regression in PV pass-through?
>   resolution: fixed
>
> * qemu-traditional: build on glibc 2.17
>   resolution: fixed
>
> * acpi-related xenstore entries not propagated on migrate
>   resolution: for 4.4
>
> * mac address changes on reboot if not specified in config file
>   resolution: for 4.4
>
> * xendomains bug
>   resolution: fixed
>
> * pv shutdown race
>   resolution: not a Xen bug (still being tracked)
>
> * libxl cpuid features for sse4* don't match linux features
>   resolution: fixed
>
> * qxl not actually working
>   resolution: disabled for now, fix for 4.4
>
> == Open bugs ==
>
> * Migration w/ qemu-upstream causes stuck clock
>  > http://osdir.com/ml/general/2013-05/msg30029.html
>  status: Root cause not yet found
>  priority: high

This is the only bug I'm tracking right now that we might consider a blocker.

On the other hand, I've been unable to reproduce the problem on my
systems so far, so it may be a more isolated instance.

> * xl does not handle migrate interruption gracefully
>   > If you start a localhost migrate, and press "Ctrl-C" in the middle,
>   > you get two hung domains
>   status: Probably not for 4.3
>
> * libxl / xl does not handle failure of remote qemu gracefully
>   > Easiest way to reproduce:
>   >  - set "vncunused=0" and do a local migrate
>   >  - The "remote" qemu will fail because the vnc port is in use
>   > The failure isn't the problem, but everything being stuck afterwards is
>   status: Probably not for 4.3

I think these will probably need more work than we're really willing
to do right now given the (lack of) severity -- any thoughts?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel