Jean McCormack wrote: > Sarah, > > Thanks again for the input. I'll try to recap here a bit of what we > talked about on the phone. > > - We agreed that for dry run, having an easily parsable output with > the information used to determine the install > would be fine even if it's just a matter of outputting what the put > in. After talking with Andre, given the current options > these are target disk, slice/partitioning changes, IPS repo to use, > packages to install, packages to uninstall, auto reboot or not, > user account to install (username, user password, description, root > password and timezone) and hostname. > > Requirement upon the engine: The ability to collect data in user > readable format along the way during an install. And retain that data > for later output. > > - We had some confusion about dry run vs stopping. I believe we came > to agreement that dry run would be equivalent to > stopping at a specific step. That step would be before there were any > changes to the disk but after all the computation > of what/where has been done.
This wasn't what I was thinking dryrun to be. If dryrun is just stopping at a specific step, why are we defining dryrun as an entity at all? I was thinking dryrun to be a complete end-to-end run of the install process, minus any disk write activity. I was also thinking that dryrun is totally separate from the start/stop points feature, but that they could be used together if desired. > > Requirement upon the engine: Provide defined points where stopping an > install would work and not modify the user system(in the case of dry > run). > > - We don't really need the pause/resume functionality. We do need the > ability to keep information that was in memory that will then be > provided to the client when a restart is done. An example is the > target disk. How does the recorded information at a stopping point get fed back into the installer when user decides to start the install again? Once a stop has occurred, can we resume from where we stopped? Can we resume and also tell it where to stop next? Do we have to always restart from the beginning again? As a developer, I find it useful to be able to: 1. stop, get a shell to poke around, resume the installation from where I stopped. 2. stop, get a shell to poke around, restart the installation from some point I've already passed. 3. stop, get a shell to poke around, restart the installation from the beginning. the "get a shell to poke around" part is really not an issue for AI, since there's always the console login shell available for that. > > Requirement upon the engine: Provide the ability to stop and restart > retaining internal state information needed for the install to > continue from a restart. > > Requirement upon the engine: The ability to stop and restart the > engine at defined spots. > > Items we didn't discuss but I want to get out there. The user > interface. For dry run and stop, we need to allow the user > to reboot with options that will indicate the action they want > performed. To do so, we can modify the boot line to contain > either dryrun or a step to stop at. The boot line modification would > be performed with use of the installadm create-client -b > <property=value> flag. property would be stop_at, value would be > dryrun or a step. Are dryrun and the start/stops points functionality intended to be supported public user interfaces? thanks, -ethan > > Jean > > > 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. >> >> >>> 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? >> >> >>> 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? >> >>> 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 >> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
