Hi,
I write a very simple DVD auto install test script by referring Will Woods's install script.Many thanks for Will.:) This is my first Python script,it is definitely not good. I will take this script as a starting-point,hope can write some high-qualified scripts in the future.
This script only supports DVD + kickstart install. If you want to try it,please modify the attached ks.cfg to specify install source first. this kickstart file can be accessed by http or ftp. Before run it, you need to install virtualization,python-virtinst... Run the script like this:
mount -o loop DVDImage.iso /InstallTree ./dvd_install.py -k http://server/ks.cfg -a i386 -d /InstallTree |tee test.log
I did not put it to git because some account issues. I will upload later. See the attachments.
Thanks Liam
On Fri, 2010-01-29 at 14:36 +0800, Li Ming wrote:
Hi,
I write a very simple DVD auto install test script by referring
Will Woods's install script.Many thanks for Will.:) This is my first Python script,it is definitely not good. I will take this script as a starting-point,hope can write some high-qualified scripts in the future.
Nice work Liam! Keep 'em coming :)
This script only supports DVD + kickstart install. If you want to try it,please modify the attached ks.cfg to specify install source first. this kickstart file can be accessed by http or ftp. Before run it, you need to install virtualization,python-virtinst... Run the script like this:
mount -o loop DVDImage.iso /InstallTree ./dvd_install.py -k http://server/ks.cfg -a i386 -d /InstallTree |tee test.log
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?
Thanks, James
[1] https://fedoraproject.org/wiki/QA:Fedora_13_Install_Results_Template#Test_Ma...
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.
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... Let's update this to ticket #107
Thanks Liam
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.
Let's update this to ticket #107
Sounds good!
Thanks, James
On 02/02/2010 03:59 AM, James Laska wrote:
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.
I did not have a deep exploration for the virt-install. When use this command,it seems that "virt-install --location" is very similar with pxe install.That means the virt-install will go to the location(local directory,http,ftp,etc...) to download the boot image(kernel) and append the kickstart to the kernel, I don't know how the virt-install did this.But if we use "virt-install --cdrom",even we specify the ks=http://server/ks.cfg, the system was booted up as local DVD, but the ks can not append to grub command line? so the kickstart install can not be started? But we really see the problem that specify the ks as http:// is not a good thing,this will need the network. I will do some investigation about the virtual-disk to add kickstart file as you said above.
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.
Our goal is to make installation automatic, if you can help me to estimate which method is better to save time and energy, I'd like to follow.
Thanks Liam
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.
Regards, Liam
On 02/03/2010 02:54 PM, Li Ming wrote:
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.
I add this function to dvd_install.py, the script supports both local kickstart file and remote http/ftp kickstart file now.More details please download and run :
http://git.fedorahosted.org/git/autoqa.git?p=autoqa.git;a=tree;f=tests/anaco...
like I can run :
mount -o loop F12gaDVD.iso /media ./dvd_install.py -k /var/www/html/ks.cfg -a i386 -d /media
Thanks Liam
On Wed, 2010-02-03 at 18:02 +0800, Li Ming wrote:
On 02/03/2010 02:54 PM, Li Ming wrote:
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.
I add this function to dvd_install.py, the script supports both local kickstart file and remote http/ftp kickstart file now.More details please download and run :
http://git.fedorahosted.org/git/autoqa.git?p=autoqa.git;a=tree;f=tests/anaco...
like I can run :
mount -o loop F12gaDVD.iso /media ./dvd_install.py -k /var/www/html/ks.cfg -a i386 -d /media
Nicely done!
I'm hoping there is a way for us to install from ISO media while also booting the ISO media (e.g. virt-install --cdrom). Worst case, I think we'll need to explode the DVD, update the syslinux kernel args, then build the ISO again. That sounds like an unpleasant way to accomplish a media-based boot+install. Are there other ideas?
Maybe the virt folks (virt@lists.fedoraproject.org) have some suggestions for how we can pass kernel arguments to a cdrom-based guest install?
Thanks, James
autoqa-devel@lists.fedorahosted.org