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.
Thanks,
Jack
