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. > 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. > 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. > > 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? > 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. > > 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 you find a preexisting Solaris or Opensolaris instance on a disk which is not a boot disk, will it be considered? > > 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. 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? target_select_unformatted_disk doesn't follow the naming convention like 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? > > 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? > > > 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. 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. > >
