[KVM_AUTOTEST] unattended installs take 2

[KVM_AUTOTEST] unattended installs take 2

[David Huff]

Second pass at the unattended install test.  Both Linux and Windows guests are
working however currently it just uses the existing boot test and extends
timeouts.  We still need a good way of determining if an unattended install
completed without error. For Linux guest we should be able to run something
similar to a regular boot test, after reboot try to ssh in.  For windows guest
we still have to run setup in order to have shh up.

Requires the processor patch as well as the patch to "strip and split" patches.

Scripts still uses loop back mounts for now we can upgrade this in the future
however most generic way of creating and manipulating disk images.

5 patches in this set
0005-Modified-boot-test-in-kvm_test.py.patch
0004-Added-two-sample-unattended-config-files-Fedora-and.patch
0003-added-unattended.sh-script.patch
0002-modified-config-file-to-run-unattended-install.patch
0001-Added-floppy-and-tftp-options-to-qemu-command.patch

Re: [KVM_AUTOTEST] unattended installs take 2

[Yaniv Kaul]

On 6/19/2009 12:50 AM, David Huff wrote:
> Second pass at the unattended install test.  Both Linux and Windows guests are
> working however currently it just uses the existing boot test and extends
> timeouts.  We still need a good way of determining if an unattended install
> completed without error. For Linux guest we should be able to run something
> similar to a regular boot test, after reboot try to ssh in.  For windows guest
> we still have to run setup in order to have shh up.
>    
The unattended script can run at the end user defined commands. Those 
could be 'setup SSH and run it'.
Y.
> Requires the processor patch as well as the patch to "strip and split" patches.
>
> Scripts still uses loop back mounts for now we can upgrade this in the future
> however most generic way of creating and manipulating disk images.
>
> 5 patches in this set
> 0005-Modified-boot-test-in-kvm_test.py.patch
> 0004-Added-two-sample-unattended-config-files-Fedora-and.patch
> 0003-added-unattended.sh-script.patch
> 0002-modified-config-file-to-run-unattended-install.patch
> 0001-Added-floppy-and-tftp-options-to-qemu-command.patch
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [KVM_AUTOTEST] unattended installs take 2

[Lucas Meneghel Rodrigues]

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

On Thu, 2009-06-18 at 17:50 -0400, David Huff wrote:
> Second pass at the unattended install test.  Both Linux and Windows guests are
> working however currently it just uses the existing boot test and extends
> timeouts.  We still need a good way of determining if an unattended install
> completed without error. For Linux guest we should be able to run something
> similar to a regular boot test, after reboot try to ssh in.  For windows guest
> we still have to run setup in order to have shh up.
> 
> Requires the processor patch as well as the patch to "strip and split" patches.
> 
> Scripts still uses loop back mounts for now we can upgrade this in the future
> however most generic way of creating and manipulating disk images.
> 
> 5 patches in this set
> 0005-Modified-boot-test-in-kvm_test.py.patch
> 0004-Added-two-sample-unattended-config-files-Fedora-and.patch
> 0003-added-unattended.sh-script.patch
> 0002-modified-config-file-to-run-unattended-install.patch
> 0001-Added-floppy-and-tftp-options-to-qemu-command.patch

I've been trough the changes, thank you for your work David:
Comments/questions:

 * Any particular reason why you guys wrote the PXE boot setup as a
shell script instead of a python module (that could be also used as a
stand alone program)? 
 * The script had some unused variables, and some extra debugging
statements would be helpful. I've modified the original script a bit and
I am attaching it to this message, please verify if the changes make
sense.

Your changes are an excellent starting point for getting unattended
installs integrated. So things I'd like to explore:

 * Turn the script into a python module
 * See whether the development version of cobbler already handles
windows appropriately. Maybe for now cobbler is not an option, but we
can revisit it in the future.
 * Create an install test that would take as the parameter the type of
installation we want to perform (steps/unattended).

Any comments/suggestions please let me know.

Lucas

[-- Attachment #2: unattended.sh --]
[-- Type: application/x-shellscript, Size: 6009 bytes --]

Re: [KVM_AUTOTEST] unattended installs take 2

[Michael Goldish]

----- "Lucas Meneghel Rodrigues" <lmr@redhat.com> wrote:

> On Thu, 2009-06-18 at 17:50 -0400, David Huff wrote:
> > Second pass at the unattended install test.  Both Linux and Windows
> guests are
> > working however currently it just uses the existing boot test and
> extends
> > timeouts.  We still need a good way of determining if an unattended
> install
> > completed without error. For Linux guest we should be able to run
> something
> > similar to a regular boot test, after reboot try to ssh in.  For
> windows guest
> > we still have to run setup in order to have shh up.
> > 
> > Requires the processor patch as well as the patch to "strip and
> split" patches.
> > 
> > Scripts still uses loop back mounts for now we can upgrade this in
> the future
> > however most generic way of creating and manipulating disk images.
> > 
> > 5 patches in this set
> > 0005-Modified-boot-test-in-kvm_test.py.patch
> > 0004-Added-two-sample-unattended-config-files-Fedora-and.patch
> > 0003-added-unattended.sh-script.patch
> > 0002-modified-config-file-to-run-unattended-install.patch
> > 0001-Added-floppy-and-tftp-options-to-qemu-command.patch
> 
> I've been trough the changes, thank you for your work David:
> Comments/questions:
> 
>  * Any particular reason why you guys wrote the PXE boot setup as a
> shell script instead of a python module (that could be also used as a
> stand alone program)? 
>  * The script had some unused variables, and some extra debugging
> statements would be helpful. I've modified the original script a bit
> and
> I am attaching it to this message, please verify if the changes make
> sense.
> 
> Your changes are an excellent starting point for getting unattended
> installs integrated. So things I'd like to explore:
> 
>  * Turn the script into a python module
>  * See whether the development version of cobbler already handles
> windows appropriately. Maybe for now cobbler is not an option, but we
> can revisit it in the future.
>  * Create an install test that would take as the parameter the type
> of installation we want to perform (steps/unattended).

I don't see a very good reason to implement that last item, since:
- we can already easily select tests in the config file with 'only install' or 'only unattended_install' (we can rename 'install' to 'steps_install'), so there's no advantage to adding an additional install type parameter,
- we might want, and probably would want, to run both 'install' and 'unattended_install' in long test sets (weekly or longer ones),
- both install tests are already quite complex -- creating a wrapper for them would make them slightly more complex

What do you think?

Thanks,
Michael

Re: [KVM_AUTOTEST] unattended installs take 2

[Lucas Meneghel Rodrigues]

On Mon, 2009-06-22 at 02:20 -0400, Michael Goldish wrote:
> ----- "Lucas Meneghel Rodrigues" <lmr@redhat.com> wrote:
> 
> > On Thu, 2009-06-18 at 17:50 -0400, David Huff wrote:
> > > Second pass at the unattended install test.  Both Linux and Windows
> > guests are
> > > working however currently it just uses the existing boot test and
> > extends
> > > timeouts.  We still need a good way of determining if an unattended
> > install
> > > completed without error. For Linux guest we should be able to run
> > something
> > > similar to a regular boot test, after reboot try to ssh in.  For
> > windows guest
> > > we still have to run setup in order to have shh up.
> > > 
> > > Requires the processor patch as well as the patch to "strip and
> > split" patches.
> > > 
> > > Scripts still uses loop back mounts for now we can upgrade this in
> > the future
> > > however most generic way of creating and manipulating disk images.
> > > 
> > > 5 patches in this set
> > > 0005-Modified-boot-test-in-kvm_test.py.patch
> > > 0004-Added-two-sample-unattended-config-files-Fedora-and.patch
> > > 0003-added-unattended.sh-script.patch
> > > 0002-modified-config-file-to-run-unattended-install.patch
> > > 0001-Added-floppy-and-tftp-options-to-qemu-command.patch
> > 
> > I've been trough the changes, thank you for your work David:
> > Comments/questions:
> > 
> >  * Any particular reason why you guys wrote the PXE boot setup as a
> > shell script instead of a python module (that could be also used as a
> > stand alone program)? 
> >  * The script had some unused variables, and some extra debugging
> > statements would be helpful. I've modified the original script a bit
> > and
> > I am attaching it to this message, please verify if the changes make
> > sense.
> > 
> > Your changes are an excellent starting point for getting unattended
> > installs integrated. So things I'd like to explore:
> > 
> >  * Turn the script into a python module
> >  * See whether the development version of cobbler already handles
> > windows appropriately. Maybe for now cobbler is not an option, but we
> > can revisit it in the future.
> >  * Create an install test that would take as the parameter the type
> > of installation we want to perform (steps/unattended).
> 
> I don't see a very good reason to implement that last item, since:
> - we can already easily select tests in the config file with 'only install' or 'only unattended_install' (we can rename 'install' to 'steps_install'), so there's no advantage to adding an additional install type parameter,
> - we might want, and probably would want, to run both 'install' and 'unattended_install' in long test sets (weekly or longer ones),
> - both install tests are already quite complex -- creating a wrapper for them would make them slightly more complex
> 
> What do you think?

Fair enough, at first I thought it'd be good for the purposes of
organization, but you made a good point against it. Let's work on the
other points.

> 
> Thanks,
> Michael
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [KVM_AUTOTEST] unattended installs take 2

[David Huff]

Lucas Meneghel Rodrigues wrote:
> I've been trough the changes, thank you for your work David:
> Comments/questions:
> 
>  * Any particular reason why you guys wrote the PXE boot setup as a
> shell script instead of a python module (that could be also used as a
> stand alone program)? 

We decided to use environmental scripts to set up any host specific 
prerequisite priour to execution any tests.  This way there would be a 
standard/preferred way for tests to set up a specific environment on the 
host.

I am including a snippet form a previous email explaining why we went 
down this path...

Michael Goldish wrote:
 > The solution I had in mind was to add pre/post-processor parameters 
'pre_command' and 'post_command' that represent shell commands to be 
executed before/after the test. A typical shell command would be one 
that runs an environment specific script that sets up mount points or 
whatever is needed for the test. This parameter would be provided for 
each test (in the config file) so one can 'variant' on it, to make 
different variants of the test (e.g. 'dbench' with local storage, and 
then with NFS storage, ...). There can also be pre/post-processing 
scripts for the entire job, that run before the first test and after the 
last one.
 > If you use a setup_<testname> function you require the user to change 
kvm-autotest code in order to perform environment specific setup (and 
you also limit the user to python). I personally prefer to leave all 
environment specific stuff in external scripts outside the code, but I 
may be wrong.


comments.....

-D

Re: [KVM_AUTOTEST] unattended installs take 2

[Lucas Meneghel Rodrigues]

On Mon, 2009-06-22 at 09:13 -0400, David Huff wrote: 
> Lucas Meneghel Rodrigues wrote:
> > I've been trough the changes, thank you for your work David:
> > Comments/questions:
> > 
> >  * Any particular reason why you guys wrote the PXE boot setup as a
> > shell script instead of a python module (that could be also used as a
> > stand alone program)? 
> 
> We decided to use environmental scripts to set up any host specific 
> prerequisite priour to execution any tests.  This way there would be a 
> standard/preferred way for tests to set up a specific environment on the 
> host.
> 
> I am including a snippet form a previous email explaining why we went 
> down this path...
> 
> Michael Goldish wrote:
>  > The solution I had in mind was to add pre/post-processor parameters 
> 'pre_command' and 'post_command' that represent shell commands to be 
> executed before/after the test. A typical shell command would be one 
> that runs an environment specific script that sets up mount points or 
> whatever is needed for the test. This parameter would be provided for 
> each test (in the config file) so one can 'variant' on it, to make 
> different variants of the test (e.g. 'dbench' with local storage, and 
> then with NFS storage, ...). There can also be pre/post-processing 
> scripts for the entire job, that run before the first test and after the 
> last one.

I agree to the reasoning made here in general, but ultimately we do have
to maintain all external scripts. On the coding style document:

http://autotest.kernel.org/browser/trunk/CODING_STYLE

"Please use Python where possible. It's not the ideal language for
everything, but it's pretty good, and consistency goes a long way in
making the project maintainable. (Obviously using C or whatever for
writing tests is fine)."

This particular case (environment setup) is not a reason good enough to
break this principle - we are doing high level stuff, so it ends up
being the same coding it in python or shell script, and in such cases,
the general principle says we should go python.

> > If you use a setup_<testname> function you require the user to change 
> kvm-autotest code in order to perform environment specific setup (and 
> you also limit the user to python). I personally prefer to leave all 
> environment specific stuff in external scripts outside the code, but I 
> may be wrong.

See comment above. Limiting the choice of languages here is good
maintainability wise, and it's compliant with the upstream guidelines.

Good to stress at this point that I have nothing against shell, perl,
ruby and other fine languages (I actually like them). This is just an
attempt to be consistent.