Sarah Jelinek wrote: > Hi Jean, > > A few comments/questions inline... >> >> 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. > > In the case where the user has not specified a 'target' device, or > other algorithmically determined choices that AI does, then I can see > why outputting the results that would have occurred. If the user > defines things specifically then would we just provide their input as > the output? or are you expecting that we would do some processing in > the engine that would determine if we came up with the same data? I > can't see how this would be different from what the user specified. In that case you are correct and it should be the same as what the user specified. Of course as a user, wouldn't that be nice to know? > > >> 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. >> > > Seems to me that dry run is more than just a specific case of stopping > the client. The install either runs or not. With dry-run it doesn't > run, but it does go through some processing to determine what the > installed system would look like. Stopping and starting the client > similar to what DC does today with checkpointing would result in some > changes to the client, correct? Let's talk about this tomorrow since I'm not 100% on what you mean. > > >> 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. >> >> > Why couldn't we use zfs snapshots to enable a stop/start feature? Is > there state outside what we have done to the alternate root that we > keep in the client in some other way?
We don't have zfs at this point in the install. The state I'm talking about is the state with what is now auto-install. We figure out things like the disk, slices etc, keep this state and pass it into functions further down. If we stop after figuring out the disk, what do we actually send to liborchestrator? Jean > >> 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. > > From the install 'engine' point of view it seems the requirements from > this project to the engine project are: > -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). > -If it is decided that checkpointing is something we want to do for > users with regard to the AI client, then the engine would have to be > modified to provide the set of points where this is possible without > loss of data. > > -The engine would also have to be responsible for the 'snapshotting' > of the data to enable restarting after a stop. > > thanks, > sarah > > > >> >> Jean >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
