Jack Schwartz wrote: > Hi Jean and Karen. > > On 05/27/09 13:47, Jean McCormack wrote: >> Karen Tung wrote: >>> Hi Jean, >>> >>> Some comments in-line. I also have a question at the end of this >>> discussion. >>> >>> Jean McCormack wrote: >>>> >>>> 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. >>>> 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. >>>> >>>> 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. >>> Given the requirements you stated above, I think that one way that >>> would work to solve the problem is >>> to create a "complete final manifest" file after all the >>> pre-processing by the client (choosing the disk, slices...etc..). >>> This file could even include all the state information that's needed >>> to actually start the installer. >>> If pause/stop is not selected, the file will be passed directly to >>> the installer engine. If pause/stop is selected, >>> the installer engine can restart when given this "final manifest" >>> with all needed info to restart. >>> That way, the user will know for certain what parameters are used >>> for the install. >>> If they want, the user can even save this file somewhere and use it >>> as input for the next time >>> they do AI install, and they know for sure what will happen. >> That's actually something similar to what Sarah and I discussed. Some >> file to contain the state. We'll need to retain this idea for use >> during our detailed design phase. >> >>>> >>>> >>>> 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. >>> If we have the "final manifest" described above, the installation >>> steps can be broken up, >>> and the install can stop and restart at anytime just >>> like DC does today using ZFS snapshot, since we would have all the >>> information needed for the whole install. This assumes >>> that no other state information is generated that need to be passed >>> around after the installation starts. >>> Is there such info that you know of right now? >> There are parts of the install where zfs snapshots aren't available >> yet. So depending upon that functionality at this point isn't >> something we want to do. >> >>> >>>> >>>> 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. >>>> >>>> Jean >>>> >>>> >>> With your design on this component, what kind of semantic validation >>> are you planning to do with the user's input? >>> When are you planning to do the semantic validation, and how are you >>> going to do the validation? >>> I am asking because in the semantic validation part of >>> the XML parser redesign effort, I would need to have this kind of >>> information. >> At this point in time, I'm not sure it will need any semantic >> validation from the XML parser. Since the manifest comes in rather >> late in the install, it's not the preferred way of interacting with >> the user. > Surely a user will be able to explicitly state a field in a manifest. > What about users and passwords? Those aren't going to be derived or > determined by the installer. There's also been lots of discussion > about disk specifications in the manifest. These fields also include > fields which, when not explicitly specified by a user, would otherwise > be given a derived default value. > > As long as there is user input in a manifest which requires validation > above the syntax checking afforded by schemas, then there is a need > for semantic validation. > > > A different issue is *where* that semantic validation will be done. > Will it be done in the parser, or will it be done in the installer > code itself? IMO it is more maintainable to do it in the parser, > because both the server and the client can do the checks from the same > "template", and keep all validation code in one place. > > This assessment is part of the XML parsing work AI is one customer of > that work. If all projects (AI and DC) decide parser-based semantic > validation isn't needed, then it doesn't need to get done. Please let > the XML parsing rework team know.
Sorry. I thought Karen was talking explicitly about the user control issue. For that I didn't see anything beyond what the client project in general needs. Have you received the client project requirements? Jean > Thanks, > Jack >
