Sarah,
> Hi All,
>
> Attached is a list of notes, and questions, that I came up with for
> Slim with regard to the changes required in the Orchestrator to
> support the new TI and Transfer modules. Plus some additional stuff we
> need to handle somehow. Hopefully they are not too cryptic. If they
> are, ask questions. I tried to think of all the changes required for
> the orchestrator to support slim but certainly may have missed some
> things. I am hoping Sundar will review this list and let me know. Jan
> and Moinak.. there are questions for you in this doc as well.
>
> In terms of Orchestrator changes, the biggest issue that we have is
> that we need to have the api's to plug in to for the TI and Transfer
> services to get the changes made, and then tested. We need to clearly
> understand the api's we will be using. So, based on Jan's estimate of
> 2 weeks, and Moinak's of 3, we cannot really start too much of the
> orchestrator, except perhaps stubbing in the calls, for at least 2
> weeks. Testing and validation requires working subordinate services. I
> need some data on the Transfer service in particular at this point.
> And,I need more data on the TI design. I would estimate 2 weeks for
> changes to orchestrator. I do think that TI needs more than 2 weeks
> based on additional callback support that must be added.
Based on your list of changes, 2 weeks for orchestrator is not enough
>
> We need to handle post install tasks as well, which will require about
> a weeks worth of work. Just so folks know we have additional work to
> add to the schedule.
>
> Please review, answer questions, ask questions.
>
> Regards,
> sarah
> ------------------------------------------------------------------------
>
> -Whole disk or existing Solaris partition only acceptable targets is current
> requirement for Slim.
>
I am assuming that the GUI handles this part and no changes required in
Orchestrator.
> -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?
>
It is easy to do, if we decide to exclude existing instances.
> -What about liborchestrator dependencies? I assume the pkgs that
> contain these dependencies, and the libtd dependencies are on
> the cd?
>
Are you thinking about libspmi libaries, libdiskmgt etc?
> -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?
>
> -Why do we need the filesystem mountpoint specification in the nvlist
> when creating a target?
>
> -Passing in fdisk data to TI? How will this be done?
>
> -root pool properties to TI? Or for slim is this assumed to be 1 type of
> root pool?
>
> ****For setting up zfs root pools we need to:
>
> -Autogenerated filesystems to be created by TI? See zfsboot stuff
> on opensolaris.org
>
> -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.
>
> -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?
>
> ****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.
>
Do we need to validate the partition data since the user is not allowed
to change partition information?
> -What to pass to TI:
> -disk name
> -use whole disk or not
> -pool name
>
- vtoc slice information
> -What to pass to Transfer:
> -root pool name
> -dataset layout
> -locales chosen
>
- Mounted alternate root directory to write data, callback function
> -What we will need is the size of the image we are installing. To ensure
> that the size of the partition/disk is sufficient.
>
- Orchestrator create user's home directory under /export/home. The code
assumes that /export/home is created already by the installer. This
needs to be revisited.
- Orchestrator also copy profile along with install logs. This should be
removed.
- GUI accepts both Linux Swap and Solaris 2 as valid Solaris partition.
Since we don't have to deal with Linux Swap in Slim, this should be changed.
-
>
> ****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
>
> -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?
>
> 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?
>
- How will Orchestrator handle failure with TI and Transfer module?
- Will there be a common install_log for TI, Orchestrator, and Transfer
Modules?
- Is transfer module a binary or a library function?
- Sundar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20070924/33e95b4a/attachment.html>
