[Xen-devel] Re: [PATCH] [Xm-Test] XenManagedDomain and initial test case for vTPM management using xen-api

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Fri, Dec 01, 2006 at 01:07:55PM -0500, Stefan Berger wrote:

> Ewan Mellor <ewan@xxxxxxxxxxxxx> wrote on 12/01/2006 12:36:47 PM:
> 
> > On Tue, Nov 28, 2006 at 04:37:31PM -0500, Stefan Berger wrote:
> >
> > > This patch provides XmTestManagedDomain and XenManagedDomain classes
> > > similar to the XmTestDomain and XenDomain classes. I have wrapped the
> > > xen-api for VM configuration creation, starting and stopping of VMs
> and
> > > destruction of the VM configuration in the XenManagedDomain class's
> > > methods. No device-related functions are provided through the class.
> > >
> > > The managed domains' UUIDs are tracked and all created VMs are
> destroyed
> > > upon failure or skipping of the test or by calling
> > > xapi.vm_destroy_all().
> > >
> > > I am adding a new grouptest 'xapi' for running xen-api tests.
> > >
> > > Only caveat: I am using an empty username and password
> > > (XmTestList/xapi.py) with Xend's authentication deactivated to run
> these
> > > tests.
> > >
> > > Signed-off-by: Stefan Berger <stefanb@xxxxxxxxxx>
> >
> > Applied, thanks Stefan.  Now all we need is some tests that _don't_ need
> a TPM
> > ;-)
> 
> Yes, I understand that, but I must say that I don't know what would be the
> best way to go about it and maybe what has been committed so far is not
> that good. One could either cut and paste all existing tests and modify
> them to work with the xen-api, or we could use a global variable 'xapi'
> that allows us to resuse existing tests like this:
> 
> if (xapi)
>         domain = XenManagedTestDomain()
> else
>         domain = XenTestDomain()
> 
> This way all tests would need to be run twice.
> 
> And then the question is whether XenManagedTestDomain() should not rather
> be implemented with XenTestDomain(managed=xapi), which would lead to a
> messier implementation inside XenTestDomain().
> 
> Often there are statements in the tests like traceCommand('xm xyz'), which
> would also need to be surrounded with an if (xapi) statement. I guess the
> goal could be to reduce the test implementation work while not messing up
> the implementations.
> 
> Thoughts?

Well, my first concern is to get the new lifecycle commands covered --
that's xm new, start, delete, suspend, resume.  For those, there's no
need to address the worries that you have, because of course those
commands aren't supported in the non-managed case.

The next set of things to test is the negative cases around VM lifecycle
-- do you get good error messages when trying to resume a VM that isn't
suspended, or start one that's already running, and so on.  I know for
sure that we're getting this wrong at the moment, and the error
messages that you get back are very poor, so coverage here would be
valuable.

Next week, I intend to add a config file to xm, so that xm itself can
decide whether it is talking to the old server or the new, and which
username and password to use when talking to the new server.  Then,
xm-test will be able to run the main body of the tests twice, once
talking to the old server and once talking to the new, without us having
to change xm-test itself too much.  All those traceCommand calls should
just work without change.

For Xen 3.0.4, the default for this flag will be to talk to the old
server of course, because the Xen-API work is only going to be available
in preview form for that release.  It will be good to be able to test
both old and new, nonetheless.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel