From: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
To: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: Xen Roadmap proposal
Date: Mon, 17 Jul 2006 12:24:30 +0100 [thread overview]
Message-ID: <1153135471.7699.65.camel@localhost.localdomain> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D57208C@liverpoolst.ad.cl.cam.ac.uk>
I think to be successful in the market we still need to focus on
stability and we need to make usability a no 1 priority.
Whilst there is a regression test suite, it's not clear how much of the
code is actually tested by it and there are areas such as concurrency
and error inject which it is clear are hardly tested at all.
It would be useful to establish some metrics for code coverage by the
test suite and also establish some process for enumerating the tests
that need to be created to test any new feature dropped into the tree.
We need to be able to continually track how much testing work is
outstanding and make sure that we don't let ourselves get behind in
developing regression tests.
One of the difficulties with creating the test suite is that it requires
expert knowledge of the testing requirements of each area. For the
development process to be scalable it would be ideal if developers would
contribute a list of tests required to fully exercise any new features
introduced (i.e. a test plan) and a set of implemented tests as well.
This has been happening already to some extent which is good but I think
we need to see a bit more of it.
If I were developing a hypervisor from scratch, I would make it
self-hosting simply because it would make testing easier: it would be
possible to bring up a cluster of hypervisor instances on a single
physical machine and, for example, simulate the effect of power failure
during inter-machine migration. With this kind of environment and
random simulated error injection and random management API calls with
probability distribution chosen to maximise code coverage it is possible
to create a very effective regression stress test which can set a very
high threshold for code quality.
We have to start from where we are however and now that Xen is
reasonably stable in simple, good path operation, it might be time to
start some discussion about how to adapt xm-test or build a stress test
environment for testing concurrency, inter-machine operations and error
inject including the effects of power failure.
On the usability front, I think what is most lacking is a community
vision for an out-of-the-box Xen solution. Whilst it is good that on
the cutting edge the open source nature of Xen means that it is
developing in all directions at once, for market acceptance there needs
to be a core idea of a Xen product with well-defined stable supported
configurations and a supported feature set that is easy to deploy and
'just works'.
It may be the intention to leave this productization step to
distributions and other commercial interests but it's such a lot of work
and so important for success in the market that any common core effort
on this front can only be beneficial to all parties.
So, I'd place emphasis on stability backed by trusted metrics and
usability as an explicit common goal.
My 2p.
Harry.
prev parent reply other threads:[~2006-07-17 11:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-12 14:44 Xen Roadmap proposal Ian Pratt
2006-07-13 13:07 ` Xen bootloader (was: Re: Xen Roadmap proposal) Mark Williamson
2006-07-14 5:12 ` yhlu
2006-07-14 11:48 ` Mark Williamson
2006-07-14 12:10 ` Rob Bradford
2006-07-14 12:40 ` Michael Loehr
2006-07-14 15:22 ` Xen bootloader Ronald G Minnich
2006-07-14 15:21 ` Ronald G Minnich
2006-07-14 13:26 ` Xen bootloader (was: Re: Xen Roadmap proposal) Michael Loehr
2006-07-14 14:27 ` John Levon
2006-07-14 14:36 ` Mark Williamson
2006-07-14 15:02 ` John Levon
2006-07-14 15:20 ` Mark Williamson
2006-07-14 15:46 ` John Levon
2006-07-14 16:13 ` Mark Williamson
2006-07-14 16:16 ` John Levon
2006-07-14 16:26 ` Mark Williamson
2006-07-14 15:24 ` Xen bootloader Ronald G Minnich
2006-07-14 15:35 ` Mark Williamson
2006-07-14 15:37 ` Ronald G Minnich
2006-07-14 15:36 ` Richard Miller
2006-07-14 15:49 ` Mark Williamson
2006-07-14 20:45 ` Jacob Gorm Hansen
2006-07-17 8:59 ` Gerd Hoffmann
2006-07-17 11:24 ` Harry Butterworth [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1153135471.7699.65.camel@localhost.localdomain \
--to=harry@hebutterworth.freeserve.co.uk \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.