Hi Sundar,
> 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
What is your estimate on the changes then? I think a lot of it depends
on what we get and when we get the TI and Transfer api data and useable
modules for testing all of this.
>>
>> 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.
I assume this as well.
>> -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?
Yes.
>> -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?
I am not sure we need to validate. But, I thought there was a reason we
wanted to validate regardless because of possible rounding issues
causing the install to fail. With the new TI this may not be an issue.
>> -What to pass to TI:
>> -disk name
>> -use whole disk or not
>> -pool name
>>
> - vtoc slice information
Yes, we need this.
>> -What to pass to Transfer:
>> -root pool name
>> -dataset layout
>> -locales chosen
>>
> - Mounted alternate root directory to write data, callback function
What do you mean by mounted alternate root to write data? Yes, we need
to provide the call back 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.
This will still be the same I would think. I assume if we pass the
dataset data in, /export/home is a directory under the /export dataset,
so this should be something we can ask TI to do?
> - Orchestrator also copy profile along with install logs. This should
> be removed.
Correct.
> - 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.
>
Correct. GUI shouldn't accept Linux Swap.
>>
>> ****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?
I would assume we would handle the failures similar to how we handle
them today with Dwarf. We have a mechanism to handle the failure via a
callback. Is there something else you are thinking of here?
> - Will there be a common install_log for TI, Orchestrator, and
> Transfer Modules?
> - Is transfer module a binary or a library function?
>
Thanks for the review of my notes.
sarah
****
> - Sundar
>>
>
>
