Jean McCormack wrote: > 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
In addition to the purpose of a dry-run Jean sights I could also envision check pointing during a dry-run could be helpful in diagnosing issues with specific steps. For example if the install could be paused at a check point directly prior to ICT, each ICT could be executed one at a time manually to narrow down a failure or confirm updates to the ICT code. Joe
