Changing testdrive

[C de-Avillez]

On Tue, 16 Mar 2010 19:06:08 +0000
Bruno Girin <brunogirin at gmail.com> wrote:

> The VB user manual [1] details everything you need to know. You
> probably want section 8 on VBoxManage.
> 
> I'm happy to help hack / test / debug the VirtualBox options if that
> can help, although I'm no expert.
> 
> [1] http://www.virtualbox.org/manual/UserManual.html

Hi Bruno,

Thank you for your offer, and you are welcome :-)

I am copying below another email [2] that I mistakenly did not copy to
the list, for completeness. Note that he first step is already done [1].

..C..


[1] https://bugs.launchpad.net/bugs/539892

[2] On Tue, 16 Mar 2010 11:30:56 -0500
Dustin Kirkland <dustin.kirkland at gmail.com> wrote:

> > This absolutely breaks when the user wants to run VirtualBox --
> > the VirtualBox definitions are hard-coded in testdrive, so there is
> > no way a no-network test run can be done without code changing by
> > the user.
> >
> > So we should look at changing the way these parameters are passed,
> > so that both KVM and VirtualBox can profit from one single set of
> > parameters.  
> 
> Right, so Testdrive started out as being a KVM-specific way of testing
> the daily Ubuntu ISO's.  But only half of the hardware out there can
> run KVM.  So VirtualBox was bolted on after the fact.  

Yes, you told me about the VBox being hammered in yesterday on IRC. And
I think I understand what you did: you had a need -- test ISOs easily
-- and you wrote what was to be a hack to get it done. It turns out
this is a good hack (hell, *more* than good!), and suddenly someone
complained with you that there was no VBox... so you added it in. And
it would probably be used this way, except for my anal-retentive
self ;-)

> Generally speaking KVM and VirtualBox support similar features.
> Really, I just don't know how to "get at VirtualBox" from a command
> line.  For starters, I think you could just use some VB expertise and
> get them to help hack Testdrive.  

This is what I intend to do ;-), and why I sent an email to QA. I am no
VBox expert; in fact I am no virtualisation expert. I copied you so
that you would be aware of what I was doing (you are, after all, the
father of this child); I do not want to do, or propose, anything that
will go against your views.
>   
> > Additionally, right now testdrive will default to having both the
> > ISO and the image cache under the same master directory ($CACHE/iso
> > and $CACHE/img). Of course, the user *can* soft-link the
> > subdirectories, e.g. $CACHE/img -> /dev/shm. But this requires an
> > additional, manual, step before running testdrive... and I would
> > very much like to have the community running testdrive in an
> > as-easy-as-possible way.  
> 
> Open a bug and I'll hack CACHE_ISO and CACHE_IMG as config file
> options.  That's easy enough.  

Heh. Already hacked in. I will open the bug and attach a new branch. I
also added in an option to always clear out the generated image (most
important if using SHM as the target).

> As for /dev/shm, just be sure you don't run out... That's limited to
> about 1/2 of your RAM ;-)  

Well, running off /dev/shm has a lot of risks. I am well aware of
potential issues on memory starvation, having been there before on
multiple OSs.

Here's a basic view:

1. CACHE: 

1.1. if only CACHE is defined, use CACHE_IMG and CACHE_ISO off CACHE;
1.2. if either CACHE(IMG|ISO) is defined, use it.
1.3. if CACHE_IMG is set on /dev/shm, then default to remove the image
when finished (unless CLEAN_IMG is explicitly set to False).

2. Abstracting VBox and KVM parameters:

2.1. factor both KVM and VBox off mainline;
2.2. add a sequence of parameters, abstracted from the
virtualisaiton engine to be used;
2.3. based on VIRT, call either VBox or KVM, passing the abstracted
parameters.

This would probably be best done in a sequence of changes, so that
we can verify testdrive keeps on running OK.

I have not thought of all the nasty details yet, though.

..C..   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20100317/530244af/attachment.pgp>