Hi Jean, Some comments in-line. I also have a question at the end of this discussion.
Jean McCormack wrote: > > 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. Given the requirements you stated above, I think that one way that would work to solve the problem is to create a "complete final manifest" file after all the pre-processing by the client (choosing the disk, slices...etc..). This file could even include all the state information that's needed to actually start the installer. If pause/stop is not selected, the file will be passed directly to the installer engine. If pause/stop is selected, the installer engine can restart when given this "final manifest" with all needed info to restart. That way, the user will know for certain what parameters are used for the install. If they want, the user can even save this file somewhere and use it as input for the next time they do AI install, and they know for sure what will happen. > > > 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. If we have the "final manifest" described above, the installation steps can be broken up, and the install can stop and restart at anytime just like DC does today using ZFS snapshot, since we would have all the information needed for the whole install. This assumes that no other state information is generated that need to be passed around after the installation starts. Is there such info that you know of right now? > > 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 > > With your design on this component, what kind of semantic validation are you planning to do with the user's input? When are you planning to do the semantic validation, and how are you going to do the validation? I am asking because in the semantic validation part of the XML parser redesign effort, I would need to have this kind of information. Thanks, --Karen
