Jean McCormack wrote: > Karen Tung wrote: >> Hi Jean, >> >> In a few places in your message below about requirements from the >> engine, >> you mention that the engine should "provide defined points....". >> Do you mean to say that these stop points would be defined by the >> engine? >> I think that it is kinda limiting to have the stop points be defined >> by the engine. >> Each installer is different and it might make sense for them to stop >> at different points. >> I think it makes more sense for the engine to have the ability to >> accept the >> definition of stop points, and be able to stop and resume from those >> points somehow. > When talking with Sarah it actually became very blurred where the > lines are drawn. I believe, > correct me if I'm wrong Sarah, that the engine redesign will have more > clear functional blocks. > Like target discover, target initiation, transfer of bits. Then we > have more specific code to put into > these blocks. Those would be the defined points to stop at.
It is blurred where the lines are drawn. The way I see the engine at this point is that it provides common functionality used by Caiman installers. So: -target discovery -target instantiation -installation of bits -setup for postinstall tasks if we want to stop at any point during these tasks I would think the engine would have to define what was doable. Otherwise the user would have undefined results. I think that each of these tasks are stop points, that is that each of the above are 'atomic' in terms of defining a task that you can stop before or after. Stopping in the middle of say installation of bits doesn't provide anything that I can see as useful. sarah **** > > Jean >> >> --Karen >> >> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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 >> >
