Just a few general comments ... Are there additional tests we might need to perform on ISO-based media? Not sure if it makes sense in this case, but I'm thinking about tests like QA:Testcase_Mediakit_ISO_Size and QA:Testcase_Mediakit_ISO_Checksums. The install.py script used for rats_install has a method we might also wish to use to validate the composition of the DVD ISO image itself (see installer_image_test()).

I see the script installs from the mounted DVD directory using virt-install --location. This raises an interesting dilemma. I'm inclined to think that the test should use virt-install --cdrom to more closely mirror a true DVD install. But I imagine doing so makes it difficult to provide the kickstart file. Have you tried this approach already?

The type of test you chose to automate is a good choice, since it's one of the more challenging tests to automate. If we can automate the DVD install using a mechanism similar to that used by the existing install.py test, it might make our lives easier in the long run. What makes this scalable is if we have a small number of custom install scripts, but a large number of kickstart files to describe the tests. If we break down the needs of each install test [1] ... do they all have similar needs? From what I can tell, each install test needs to ... * Prepare the host environment * Define a guest environment (# and type of disks, #nics etc...) * Validate the install images * Specify a kickstart file to direct the install * Detect install progress (and timeout if needed) * Validate installed system meets kickstart criteria * Cleanup the guest environment * What other needs do install tests have?

On Mon, 2010-02-01 at 13:47 +0800, Li Ming wrote: > On 02/01/2010 10:24 AM, James Laska wrote: > >> Just a few general comments ... >> >> Are there additional tests we might need to perform on ISO-based media? >> Not sure if it makes sense in this case, but I'm thinking about tests >> like QA:Testcase_Mediakit_ISO_Size and >> QA:Testcase_Mediakit_ISO_Checksums. The install.py script used for >> rats_install has a method we might also wish to use to validate the >> composition of the DVD ISO image itself (see installer_image_test()). > > I think you are right. This is what I did not realize before. If test > DVD image, the ISO size and checksum needs to be tested first. I will > add later. > >> I see the script installs from the mounted DVD directory using >> virt-install --location. This raises an interesting dilemma. I'm >> inclined to think that the test should use virt-install --cdrom to more >> closely mirror a true DVD install. But I imagine doing so makes it >> difficult to provide the kickstart file. Have you tried this approach >> already? > > If use virt-install --cdrom argument,the kickstart file will can not be > easy put into kernel boot.That means we need to uncompress the ISO first > and then put the kickstart file to boot image? I am not sure how much > resource will be consumed, but I am afraid it will be big. Yeah, having to uncompress the ISO image would be messy. I think we'll likely employ a different mechanism for storing the kickstart file if we use virt-install --cdrom. We can either use ks=http:// or ks=hd:sda1:/ks.cfg. The former would probably be simpler, but I think it would activate networking and that interferes with the use case of a DVD or CD install. If possible, I'd be curious if we can write the ks.cfg file to the virt-disk prior to running the command virt-install. I spoke to Richard Jones on IRC about this. Richard has been developing libguestfs (http://libguestfs.org - a library for accessing virtual disk images). He suggested that guestfs (aka python-libguestfs) could be used to accomplish this and provided a sample python snippet that might help accomplish what you'd need (see attached python file). This looks promising, might be worth exploring as a way to provide the ks.cfg to the guest without needing to modify the initrd.img.

>> The type of test you chose to automate is a good choice, since it's one >> of the more challenging tests to automate. If we can automate the DVD >> install using a mechanism similar to that used by the existing >> install.py test, it might make our lives easier in the long run. What >> makes this scalable is if we have a small number of custom install >> scripts, but a large number of kickstart files to describe the tests. >> If we break down the needs of each install test [1] ... do they all have >> similar needs? From what I can tell, each install test needs to ... >> >> * Prepare the host environment >> * Define a guest environment (# and type of disks, #nics etc...) >> * Validate the install images >> * Specify a kickstart file to direct the install >> * Detect install progress (and timeout if needed) >> * Validate installed system meets kickstart criteria >> * Cleanup the guest environment >> * What other needs do install tests have? >> > > You are mentioning how to take advantage of the current existing > resource. I did not think about this before. But if we have small > customization to the install.py,that will absolutely save our time and > energy. I will write tests under autoQA framework later. I do not think > we waste some time before, at least I have a deep understanding of the > current framework,including the methods of classes, the structure, how > installation works under VM, etc... Sorry, didn't mean to imply this was a waste of time. On the contrary, I think this is tremendously useful in helping determine how to proceed with installation automation. Does it make sense to continue working in the changes to the script you've uploaded? Once you are comfortable with the changes, we can investigate the patchset as a whole and determine if it makes sense to merge into install.py.

On 02/02/2010 03:59 AM, James Laska wrote: > > Yeah, having to uncompress the ISO image would be messy. I think we'll > likely employ a different mechanism for storing the kickstart file if we > use virt-install --cdrom. We can either use ks=http:// or > ks=hd:sda1:/ks.cfg. The former would probably be simpler, but I think > it would activate networking and that interferes with the use case of a > DVD or CD install. If possible, I'd be curious if we can write the > ks.cfg file to the virt-disk prior to running the command virt-install. > > I spoke to Richard Jones on IRC about this. Richard has been developing > libguestfs (http://libguestfs.org - a library for accessing virtual disk > images). He suggested that guestfs (aka python-libguestfs) could be > used to accomplish this and provided a sample python snippet that might > help accomplish what you'd need (see attached python file). This looks > promising, might be worth exploring as a way to provide the ks.cfg to > the guest without needing to modify the initrd.img. > Your attached script works!!, I tried today,after a small modification, it can help to create an extra virtual disk and put the ks in the additional virtual disk, after the VM boots up, can read the ks from /dev/vdb1. It's so great, thanks for the information. I will add this function to dvd_install.py for the local ks file.