Hi Jan,
> Hi Sarah,
>
> I have tried to address your TI&TD questions.
> Please see my comments in line. Where no explicitly
> specified, they take into account requirements for
> Slim October release.
>
> Thank you,
> Jan
>
>
> Sarah Jelinek wrote:
>> -Whole disk or existing Solaris partition only acceptable targets is
>> current
>> requirement for Slim.
>>
>> -Target discovery via orchestrator will still returns all data, gui
>> must filter
>> appropriately. This results in no change to target discovery interfaces.
>> However, this results in a potential performance issue since the
>> discovery
>> of upgrade instances is unnecessary.
>>
>> -We could separate out os discovery from this. Currently it is
>> done after disk discovery via handle_disk_discovery. Should we do this?
>>
>
> I think that since Upgrade path won't be supported and information
> about existing
> OS instances would be left unused, discovery of OS instances might be
> omitted.
>
>> -What about liborchestrator dependencies? I assume the pkgs that
>> contain these dependencies, and the libtd dependencies are on
>> the cd?
>>
>> -what is the zfs root pool configuration for slim? mirrored or not?
>> I assume not mirrored but not sure. Since we are creating
>> a separate swap slice, outside the root pool, we will at a minimum
>> have to create a pool with the slice(s). Not sure if we are allowing
>> more than 1 disk to be included in the pool?
>>
> From TI perspective, following configuration will be supported:
> * one disk (not mirrored)
> * two slices within Solaris2 partition (one for root pool, one for swap)
> * only one ZFS pool (root pool created on slice)
> * five ZFS filesystems (root, usr, var, opt, export)
>
> Looking at the UI roadmap, mirrored configuration might be supported, but
> would be handled as one of post-installation tasks.
>
> Why would be necessary to create ZFS pool (other than root pool)
> containing
> the slices ?
>
For future stuff. Users may want to separate out root from user data
pools. So, I was just wondering if TI will allow 'non root' pools to be
created. Not for Oct, just in general.
>> -Why do we need the filesystem mountpoint specification in the nvlist
>> when creating a target?
>>
>
> You are right. For TI, filesystem mountpoint shouldn't be necessary.
> Only name
> of created ZFS file system will be required. I will remove this
> attribute from
> Design Specification (Table 5).
>
Ok.
>> -Passing in fdisk data to TI? How will this be done?
>>
>
> Following set of attributes should describe supported fdisk targets:
>
> [1] whole disk
>
> TI_ATTR_FDISK_WDISK_FL (boolean) = TRUE
> TI_ATTR_FDISK_DISK_NAME (string) = <disk_name>
>
> [2] existing Solaris2 partition
> TI_ATTR_FDISK_WDISK_FL (boolean) = FALSE
> TI_ATTR_FDISK_DISK_NAME (string) =
> <name_of_disk_containing_target_Solaris2_partition>
>
>
> It still needs to be worked out, how fdisk configuration will be
> described for March release.
>
Ok. This makes sense.
>> -root pool properties to TI? Or for slim is this assumed to be 1 type of
>> root pool?
>>
>
> Only one type of root pool is supported. For March release, there
> might be
> requirement that properties might be also specified by attributes passed
> to TI.
>
Ok.
>> ****For setting up zfs root pools we need to:
>>
>> -Autogenerated filesystems to be created by TI? See zfsboot stuff
>> on opensolaris.org
>>
>
> This is good question. I am not sure right now, if this task should be
> handled by TI or transfer module. For being able to do this, it is also
> necessary to mount appropriate filesystems before actual population
> process could start. We need to discuss this point.
>
>> -Setting up zpool.cache?
>>
>> -Setting up grub for root pool?
>> -menu.lst changes?
>>
Dave indicated Lori has an install-finish.sh script we can use. I will
ping her to get this.
>> -Extended partition support? What are we going to do for Oct?
>> Orchestrator
>> will need to be modified for this support as well.
>>
>
> This feature is targeted for March.
>
Ok.
>> -We will need to create vtoc slice for swap. How big is it going to be?
>> Based on disk size as Dwarf does this? Also, do we pass this data
>> in to the TI module?
>>
>
> In current TI design, it is assumed that VTOC configuration would be
> passed
> from orchestrator to TI (please see below).
>
> Since orchestrator currently implements algorithm for calculating slice
> configuration for Dwarf, I think that simplified version might be
> utilized
> for Slim (only one slice for ZFS root and one slice for swap will be
> needed).
>
Ok.
>> ****Postinstall tasks. We wil likely need a postinstall service to
>> handle these.
>> pfinstall/libspmi currently do this for us automatically.
>> 1. transferlist
>> 2. create boot archive
>> 3. XXX whatever else is in finish script.
>> 4. Moving, copying the logs
>>
>> ****Changes required in the orchestrator:
>>
>> typedef struct {
>> char *pool_name; /* More info will be added */
>> + zfs_dset_t *set_list; /* data sets in pool */
>> + boolean_t is_root; /* root pool */
>> } zfs_instance_t;
>>
>> -GUI will pass in the fdisk partition data to the orchestrator as
>> usual, the difference will be that the user does not select anything
>> other
>> than the disk.
>> -What to pass to TI:
>>
>
> Below I have tried to assign appropriate nv list attributes describing
> the particular part of target;
>
>> -disk name
>>
>
> TI_ATTR_FDISK_DISK_NAME (string)
>
>> -use whole disk or not
>>
>
> TI_ATTR_FDISK_WDISK_FL (boolean)
>
>> -pool name
>>
>
> TI_ATTR_ZFS_RPOOL_NAME (string)
> TI_ATTR_ZFS_RPOOL_DEVICE (string array) - will contain one slice name
> for October release
>
> I am thinking about following information, which would be passed to TI
> as well:
>
> - slice configuration
>
> TI_ATTR_SLICE_DISK_NAME (string) =
> <name_of_disk_containing_target_Solaris2_partition>
> - optional for October. It is not required if TI_ATTR_FDISK_DISK_NAME
> is defined
>
> TI_ATTR_SLICE_NUM (uint16) = 3
> TI_ATTR_SLICE_PART (uint16 array) = {0,1,2}
> TI_ATTR_SLICE_TAG (uint16 array) = {2,3,5}
> TI_ATTR_SLICE_FLAG (uint16 array) = {0,1,0}
> TI_ATTR_SLICE_START (uint32 array) = {0,??,0}
> TI_ATTR_SLICE_SIZE (uint32 array) = {??,??,??}
>
So, this does this imply that TI will do some sanity checking in terms
of the slice data? I assume so. What I mean by this is that if for some
reason the orchestrator gets the size wrong, or it gets mangled somehow,
we need to be able to either a) adjust for the appropriate size or b)
return an error back to the orchestrator.
> - ZFS file systems to be created
>
> TI_ATTR_ZFS_FS_POOL_NAME (string) = root_pool
> TI_ATTR_ZFS_FS_NUM (uint16) = 5
> TI_ATTR_ZFS_FS_NAME (string array) = {root, usr, opt, var, export}
>
Ok.
>> -What to pass to Transfer:
>> -root pool name
>> -dataset layout
>> -locales chosen
>>
>> -What we will need is the size of the image we are installing. To ensure
>> that the size of the partition/disk is sufficient.
>>
>> ****Changes for new Transfer module. Need to get api's to pass in:
>> -Target data - including pool info, datasets
>> -Language selection data - how are we going to handle this?
>> download from repository?
>>
>> -Tools install, does this still happen with Slim? If not, we need to
>> remove
>> this from the orchestrator.
>>
>> -Need new milestones for target instantiation and transfer service
>> -Disk partitioned, - estimated percentage of overall process time
>> -VTOC created - estimated percentage of overall process time
>> -zpool created - estimated percentage of overall process time
>> -datasets created - estimated percentage of overall process time
>>
>
> For now it seems that the most time consuming task would be creating
> of ZFS pool
> (It takes about 5 seconds on relatively fast system - measured on
> Ultra45).
>
> I will take a look on all particular milestones and how long they
> would take.
>
Ok.
>> -Need new milestones for Transfer service actions
>> -Total size of image we are transfering
>> -Regular updates, percent of total installed
>>
>> -Orchestrator will call TI and Transfer service. GUI will call
>> om_perform_install. GUI will have to be modified to understand the
>> new/additional milestones.
>>
>> TI notes:
>> -Will TI create swap partition? So, size of partition will need to be
>> passed in?
>>
>
> Yes. swap slice would be created as part of slice configuration task.
> Size of swap slice would be determined by TI_ATTR_SLICE_SIZE (uint32
> array)
> attribute. Please see above for other attributes describing VTOC
> structure.
>
>> Transfer service notes:
>> -Progress/milestones for putting the data on disk. What will the
>> format be for moving the data?
>> If cpio we could:
>> -Get the total number of files to be copied
>> -Use -V to have cpio output a '.' for
>> each file written. We could read the '.' and
>> update with a milestone for so many dots.
>>
>> -General questions:
>> -Gate/repository available?
>> -Build environment?
>> -How to create livecd images?
>>
>
>
Thanks for the data Jan.
sarah
****
