Jean McCormack wrote: > Ethan Quach wrote: >> >> >> 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. > In fact, the disk activity is all at the end so it's the same thing. > However, now you're making > me take a step back and I see why people are confused. I'm thinking > from looking at the current > code too much. In that case they are the same thing. However this > design needs to think about the fact that > they may not be. So dry run will be different and will be as stated, > the install process minus the disk activity.
I think defining dry run as stopping at a specific set is ok. The step we would stop at is the part right before the disk activity, that is target instantiation. So, by defining dryrun as an ease of use as stopping at this step seems like it is the same as stopping. Dryrun is effectively doing everything up to the point of modification of the system. So, even if we have an engine that does things differently than we do today, we still have to do certain things to get to the point of modification of the system, right? The following has to be done in order(I think): -target discovery -some choice of target disk based on installer type -gathering of user input, either GUI or manifest or ? -Putting that user input, plus installer determined data in to a format understood by the 'engine'. -running the engine. So, dryrun is the stop point before 'running the engine'. Am I thinking about this incorrectly? > > Jean >> >> 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? > Sarah and I discussed the possibility of recording the information in > a file which gets read when the install is restarted. That discussion > was meant as an exercise in "can we do this" and not meant as a > implementation decision. Right, we just talked mostly about could we do it. how we do it is another discussion. >> >> 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? > We can resume from where we stopped and tell it to stop again. We do > not need to restart from the beginning. Or, we can restart from the beginning. That, however is a special case. That is, if the installer is asked to restart after say having created a root pool, it would have to know to clean up the original root pool and anything else it did before starting over. >> >> 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. > We should be able to do these. >> >> >> 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. >> > Yes. >>> >>> 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? > > dryrun should be since test will be using it and people who are used > to the similar functionality in jumpstart may want it. > I'm not so sure on the start/stop functionality. My inclination is to > say no but I'd like to hear reasons for either side. > I wouldn't think stop/start should be exported as public. Dryrun should be. thanks, sarah ***** > Jean >> >> >> 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 >
