Sarah Jelinek wrote: > 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? I became concerned that with a different design there could be something that happens after running the engine. So stating more clearly seemed appropriate. I believe they actually are one and the same at this point in time.
Jean > >> >> 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 >> >
