Evan Layton wrote: > Frank Ludolph wrote: >> Dave Miner wrote: >>> Sarah Jelinek wrote: >>>> Hi Sue, >>>> >>>> Some comments on disk selection proposals: >>>>> Proposed Functional Design for Default Disk Selection >>>>> ----------------------------------------------------- >>>>> One disk on x86 system >>>>> a) Look for solaris2 partition to use. If found, use it and create >>>>> vtoc >>>>> b) If partitions exist, but no solaris2 partition exists, but >>>>> there is space for creating solaris2 >>>>> partition, create it and use it. >>>>> c1) If partitions exist, but no solaris2 partition exists, and no >>>>> space exists to create one, ask user >>>>> if they want to use whole disk or use a partition on disk (list >>>>> the partitions). If partition is chosen, >>>>> use it and make solaris 2 partition. Or user could quit and do >>>>> fdisk/format. >>>>> >>>> >>>> How exactly would we ask the user? I am a bit uncomfortable with >>>> this approach since it is supposed to be a hands off install. Which >>>> means we automatically succeed or we automatically fail. I would >>>> think the text based installer would be used, eventually, in the >>>> event a user wants an interactive install experience. >>>> >>>> Baking in behavior that requires user input in some scenarios seems >>>> contrary to what we want to provide with AI. >>>> >>> >>> More directly: it doesn't meet the requirements. Automated >>> installations must succeed (or fail) entirely without interactive >>> input. Is there any way in which this requirement is unclear? >>> >> The requirement is clear but the impact of the hands-off failure on >> the user experience is significant. Because an install will overwrite >> data, the disk/partition/slice defaults should be pretty tight which >> in turn raises the likelihood of failure. >> >> Once an install fails it is no longer hands-off. The user must take >> corrective action, in this case either reformatting a disk to match >> the disk selection criteria, or more likely editing a manifest and >> creating a new service. The latter is the right thing to do for a >> production environment (though time might be an issue in some >> instances), but it places a high hurdle for first time users >> evaluating UI using the default manifest. Asking the user to >> interactively designate a disk and possibly a partition/slice in the >> event of disk selection failure, rather than simply failing outright, >> can greatly simplify the initial out-of-box experience. >> >> I'm not suggesting that AI should initiate user interaction in other >> failure modes. Disk selection happens very early in the install >> process when the user might still be observing that the installation >> has properly started and is proceeding properly - there are progress >> messages being sent the the target machine's console. >> >> To Sarah's question of where the interaction would be done, the >> answer is the target machine's console where the progress messages >> are being printed. If there are concerns about visibility of the >> console the interaction could time out and fail the install after >> several (10?) minutes. > > Isn't having the installer in this case stop and require user input > defeating the purpose of having an automated (or hands-off) installer? > It seems that if the user is expecting a hands-off experience then > that's what they should get. If the disk selection fails then the > hands-off part of the install should fail. We could at this point give > them the choice of failing out, fixing the problem and restarting the > install or continuing with the text based installer. (just a thought...) >
I can imagine that not every system being installed with AI has a head or is being monitored specifically. So, giving an option to allow any user input would be difficult. I think that we need to consider the way we handle the errors as the real problem here. The suggestion of asking for user input is really about managing errors, correct? Currently, if the install fails the user has to be able to log on to the machine somehow, that is get a console via tip or directly, then look at the logs. This is probably the worst user experience we could give. If we found a way to provide better and more 'in your face' observability to AI, and notified the user in the chosen way, for example email, or alert or something, the user could then figure out how to resolve the issue. We need to give more information about the errors as well. We don't do a good job of reporting what the specific errors are. Again, I believe it should succeed for fail automatically. And, if the user needs to fix something, then they must boot to a text installer or manually go in and fix the issue. thanks, sarah ***** > -evan > > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
