Sundar Yamunachari wrote: > Comments on the notes inline. > > Sundar Yamunachari wrote: >> Attendees: Jean, William, Frank, Jan >> >> The agenda for the meeting was to finalize a proposed design for >> default disk selection, discuss >> specified disk selection, and get an intro from Jean on progress >> reporting. Rather than talking >> about progress reporting, we started talking about slice/partition >> editing. >> >> We began by talking about default disk selection as Frank was not >> able to be at yesterday's meeting. >> Frank's feeling is that default disk selection is scary. He suggested >> the idea of asking the user >> for input if we are not able to determine default disk (see below). >> There was some question at the >> meeting if asking for user input during an automated install process >> was a good idea, but Frank felt >> that if you were going to fail anyway, it wouldn't be very automated >> anyway. >> >> 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. > My opinion in not to ask for user input during automatic installer > which is "hands-free" installer. Frank will be responding to Dave's email on this item. >> OR >> c2) If partitions exist, but no solaris2 partition exists, and no >> space exists to create one, inform user >> via console and log, they would login to run fdisk/format and start >> install again. > The implicit requirement here is that the automated installer should > be restart the installation after the correction of failure. That was our intent, we will change the wording to be clearer. >> d) If no partitions exist, use entire disk. > I am not comfortable with the idea of using the entire disk with out > knowing what is in there. I understand that it is a single disk case.
The intent is to use the whole disk only if it is unformatted. >> >> One disk on sparc system >> a) If disk has slices, select first root slice big enough if one >> exists (first look at recommended size >> then at minimum size). > How are you defining root slice here? is it based on slice tag? or > planning to look in the slice to determine whether it is a root file > system? Current thinking is slice tag or other positive identification on the disk for the root slice. >> b) if vtoc created, but no data slices, ok to install >> c) if disk is unformatted, use entire disk > Same comment as that of X86. I am not comfortable with the idea of > using the entire disk with out knowing what is in there. Same response. >> >> Otherwise, fail. >> >> Systems with Multiple disks: >> Frank says that from user experience point of view, should: >> Give user list of disks (devices, size, etc) and ask which to use, >> listing boot disk first. >> Info should also go to log. >> >> If we don't want to ask user, the proposal is to use the boot disk >> and treat it similar to the >> single disk case above. > Can you determine the boot disk at all times? If we can't determine a boot disk it won't be used. The install would fail. The assumption is that the default case would be used by the experimental user. The production user would create manifests. > If you find a preexisting Solaris or Opensolaris instance on a disk > which is not a boot disk, will it be considered? No because we won't be looking at other disks. We are reluctant to overwrite other disks. >> >> Need feedback on asking users questions on client during AI. >> >> Note, there is currently a bug that when we install opensolaris, we >> overwrite the boot record and boot >> solaris by default. but existing linux instances are hidden. We >> recognize windows, and add to grub >> menu, but not linux. So users need to manually add linux to grub >> menu. GUI has the same problem. >> >> >> >> >> Proposed Specified disk selection functional changes: >> ----------------------------------------------------- >> We want to make specified disk selection deterministic. >> Currently, we have: >> target_device_name >> target_device_type >> target_device_vendor >> target_device_size >> target_device_use_solaris_partition >> >> Create new names with "select" to make usage clearer. Deprecate the >> existing names. >> New names will be: >> target_device_select_name >> target_device_select_controller_type >> target_device_select_vendor >> target_device_select_size (minimum size in sectors) >> Change this to accept units other than sectors (gb, mb, etc) >> target_device_select_has_solaris_partition >> >> Add following new qualifiers for disk selection: >> target_device_select_id (where id is from: iostat -iEn) >> target_device_select_volume_name (8 character volume name set by format) >> target_device_select_boot_disk >> target_select_unformatted_disk (x86: no partitions, sparc: without >> data slices (vtoc and label exist) >> or unlabeled disk. Unlabeled disk wouldn't work until 6260 is fixed) > I am not sure adding select to the tag will make it clearer. Our naming convention was an effort to distinguish between tags used to select the disk and tags used to configure the disk. In that vein, we'll keep target_device_select to select the disk and use target_device_option for the items used to configure the disk. > Do you need a qualifier to indicate 'use_whole_disk' to indicate whole > disk can be used? or is it covered by some other tag? We did talk about that(see way below) target_device_overwrite_disk now called target_device_option_overwrite_disk. > target_select_unformatted_disk doesn't follow the naming convention > like target_device_select_unformatted_disk. That was a typo, it should be target_device_select_unformatted_disk > > In the original AI design we considered choosing a disk based on size > and an operand MIN, MAX and EQUAL. If MAX is 72 GB, all the disks > greater than 72 GB will not be considered. Did this topic came in the > discussion? Currently the target size is based on min, but adding max would be a good thing as well. Equal would be subject to +- a 10% approximation. >> >> We considered: >> target_device_select_zfs_root_pool_name (name) can be several rpools >> on separate disks with same name (bug >> filed becasue zfs boot calls rpool by name, so need unique identifyier) >> Could use rpool id, so add: >> target_device_select_zfs_root_pool_guid (guid obtained from zpool get >> all <rpoolname>) >> however, William says that we can't currently replace the content of >> an rpool with new content so make this >> future enhancement. >> >> *** Selected disk much match ALL target_device_select elements that >> are specified in manifest. *** >> >> Add comment to manifest that target_device_select elements are >> "and"-ed together, >> i.e., Disk much match all target_device_select elements. >> >> What happens if no target disk is found that meets criteria? >> ->Frank suggests user interaction. >> >> What if multiple disks match criteria? >> Today, we pick the first one (non deterministic) >> Suggestions: >> Ask user >> Pick largest disk that matches (other option?) to avoid asking >> questions. >> Currently undecided how to resolve this- input welcome. > I was under the impression that you will pick the boot disk if there > are multiple disks. How will you get multiple match? That was the default case that we pick the boot disk. This is for the case where the user has specified criteria. We could get multiple matches in the very simple case where the user specified a vendor and that is all they specify. (or minimum size or type .....) >> >> >> add option: >> target_device_overwrite_disk: remove any partitioning and create a >> single partition using entire disk and use all of it for install slice >> or just use entire disk for sparc >> Need to flag during validation (both client side and server side) as >> mutually exclusive: >> target_device_overwrite_disk and any other partition/slice actions >> >> >> slice/partition editing discussion >> ---------------------------------- >> Actions are currently create, preserve, delete. >> >> It is ok to have multiple actions in some situations: >> If create action exists for slice that exists, install fails >> That is as designed, because need to delete first, then create that >> slice >> This needs better documentation. >> >> Currently, if you use preserve, anything not preserved or created is >> deleted >> If you don't use preserve, then only what is specified to be deleted >> is deleted. >> This is not a good user experience. >> >> Proposed Revision: >> A. OK to have multiple actions defined except for preserve: >> Preserve specified with any other other action needs to be manifest >> validation failure. >> B. Order of operation: >> all preserves >> all deletes >> all creates >> C. add new action for slices and partitions: delete_all > Are you planning to support using multiple disks in the manifest. All > partition and slice operations should be moved under target disk so > that they are applicable for that disk. We're investigating this further. Jean > > Thanks, > Sundar >> >> Talk to Jack about laying this out better in manifest. >> We shouldn't need to specify size for a delete, for instance >> >> We will continue discussing slice/partition editing tomorrow. >> >> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
