Ethan Quach wrote: > > > Sarah Jelinek wrote: >> Jan Damborsky wrote: >>> Jean McCormack wrote: >>>> >>>> The client has the following dependencies upon the CUD project. >>>> >>>> - The ability to collect data in user readable format along the way >>>> during an install and retain that data for later output. >>>> >>>> - Provide defined points where stopping an install would work and >>>> not modify the user system(in the case of dry run). >>> >>> For reference, with respect to the dry-run support, there is a >>> requirement >>> for particular modules to support that functionality - I can think >>> at least about >>> >>> * Target Instantiation (dry run is supported except for BE part) >>> * Transfer module >>> * ICT >>> >>> Not sure if this requirement falls under CUD or should be captured >>> at other place. > > Note here that two of the modules Jan has pointed out that would > support dryrun are write phases of install. If they support dryrun, > I don't see why dryrun would be just considered a stopping point > before phases that do writing. > > I think there's value in this type of dryrun support because you'd > actually dry run through all or at least more of the code without > doing a real install. > > > thanks, > -ethan I agree with Ethan. We should really allow dry-run for the whole install process. That way, people can choose to dry-run through the whole "install" or stop at whichever checkpoint they want. To support this, perhaps each of the "modules" that plug into the engine can support dry-run for its own module, so, there shouldn't be any special code in the engine to support dry run, probably except passing in a flag or something to indicate to the modules that we want to do dry-run instead of real install..
--Karen
