One of the areas to address in the client redesign is the issue of client control by the user.
Following are some thoughts based on discussions with various people. This is not meant to be a full fledged design put out for review but rather the start of a discussion with the community. There is currently the desire to have some user control over the client portion of the automated installer. A dry run capability has been requested for test and any others who might find such a capability useful. It is desired to have an easily parsable output that would contain the information needed to determine what the install would look like. This would be the same type of information that the user selects on the slim_install screen. Requirements of the data needed would need to be obtained from test and the community. The ability to be able to stop the client and restart it later has also been requested by development to ease the debug process. The dryrun capability is actually a specific case of the ability to stop the client. The client contains quite a bit of state information making stopping and restarting at more than a few places not feasible. However, a pause/resume type functionality, where the process would remain running until told to resume, would provide the ability to give the user many more points to interact with the install. The idea was discussed to put the "dryrun" request or the stop or pause request on the boot line. The dryrun request would be aliased to stop <stop point just before modifying disks and installing>. There would also be a stop option which would be a hard stop of the program. Execution would be stopped and state present in the program is lost. The user would need to specify at which step to stop. How to make the user aware of possible steps has not been discussed and is open for ideas. The auto-installer method would then need to allow the user to specify a start option to restart execution from the stop point. We could allow step specification on the start in case a user wanted to back up to a previous step. There still needs to be investigation as to whether this type of action would yield correct results. There would also be a pause option which would allow the user to pause the execution of the program waiting for some further input to resume execution. User input methods discussed were actual keyboard input or a signal of some kind. This functionality would allow the user to interact with the installer at many more points where state needs to be preserved to continue running. Again, how to make the user aware of the potential pause points hasn't been addressed yet. Jean
