On Mon, 2009-06-22 at 02:20 -0400, Michael Goldish wrote: > ----- "Lucas Meneghel Rodrigues" <lmr@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
