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

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@us.ibm.com>



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

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@us.ibm.com>
Applied, thanks Stefan.  Now all we need is some tests that _don''t_
need a TPM
;-)

Ewan.

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

Ewan Mellor <ewan@xensource.com> 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@us.ibm.com>
> 
> 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?

   Stefan

> 
> Ewan.

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

On Fri, Dec 01, 2006 at 01:07:55PM -0500, Stefan Berger wrote:
> Ewan Mellor <ewan@xensource.com> 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@us.ibm.com>
> >
> > 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@lists.xensource.com
http://lists.xensource.com/xen-devel