Karen Tung wrote: > 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.. I'll agree with you guys up to a point. I think the modules need to be looked at. If the module basically takes an input and then does the write what is the point? If the module takes input, does some processing that effects the write then we should. My impression is that the purpose of the dryrun is to gather the information that tells things like where and what will be installed and other configuration information. I don't believe it is considered a code path executer like some test groups use to detect percentage of code executed in a test.
Jean > > --Karen > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
