Re: [Xen-cim] Testing with own kernel and ramdisk

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

Szymanski, Lukasz K wrote:
> Jim -
>
> Just a thought from our discussion this morning ... If a user does not
> wish to run with the xm test kernel and ramdisk, but has their own
> ramdisk and kernel they are willing to expose to the rigors of our
> testing - then that should work too.  I think that would solve your
> problem of not wanting to have xm-test but having vm's on a box.  So the
> logic would go something like this:
>
> If (no xm-test)
>       Do you want to run xm-test?
>       If (no)
>               Do you want to run this test with your own vm's?
>               If (yes)
>                       Enter kernel, ramdisk, disk
>               If (no)
>                       Just run extrinsics.
>
> Thoughts?  If we go with this approach, does the 'make runtest' solution
> still make the most sense?
>   

Initially, I think the logic should just simply be

If (xm test found)
    do whatever necessary to 'build' xm test ramdisk if not already built
    call DefineSystem() to create a vm with sane config that uses ramdisk
    activate vm with RequestStateChange
    run existing instance and association interface tests
    deactivate vm with RequestStateChange
    call DestroySystem() to nuke vm
else
    run existing instance and association interface tests

When xm test is found, this logic will already test some stuff not
currently tested, e.g. the extrinsic methods [Define|Destroy]System and
RequestStateChange.  We can certainly add a lot later, e.g. checking
properties against known configuration, executing additional extrinsic
methods, etc.

I'm happy with the 'else' case above staying as it is.  I don't think
there is a need to support, in an automated fashion, the myriad of vm
configurations a user may have.

I don't see a problem with this logic being invoked by 'make runtest'
target.

Jim

> Luke
>
> _______________________________________________
> Xen-cim mailing list
> Xen-cim@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-cim
>   

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