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 ?
> -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).
> -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.
> -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.
> ****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?
>
> -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.
> -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).
> ****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) = {??,??,??}
- 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}
> -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.
> -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?
>
