Hi Sue, I tried not to repeat Karen's input. My comments/questions:
> 2.4.3.2: Output > Returns an array of DiskInfo objects Is what you expect that will be part of the libtd python bridge? I am wondering if it would be better to have a function that returned an nvlist of disk info data, so that it isn't specific to the definition of a DiskInfo object? I would think the libtd python bridge would provide functions that model the current C functions offered in libtd. It seems that there will be more consumers than the text installer for the libtd pymod and validation module pymod. We need to ensure that the design for the validation module and data required for this validation, is not only useful for text installer and other consumers. Same comments for other common functionality, such as setting time and locale. > 2.5.4: Function: configure_network > Static IP information will be entered on its own screen. The information > passed in by the user will be > checked for validity, then used to configure the installed system's > networking. Both IPv4 and IPv6 will > be accepted. Wouldn't it be useful to have a common function for other consumers to use? I think AI would be a good consumer for this. Also, is this part of post installation processing? > 2.5.7: Function: instantiate_target > 2.5.7.1: Input > A DiskInfo object > 2.5.7.2: Output > None > 2.5.7.3: Errors > TargetInstantiationError (extends InstallationError: see perform_install) ? > Thrown if an error occurs > during calls into py_ti_create_target > 2.5.7.4: Details > This function is a small wrapper around the Python function > py_ti_create_target. It converts a DiskInfo > object into the format expected by py_ti_create_target, and then calls > py_ti_create_target. If > py_ti_create_target returns an error, an exception is thrown. > 2.5.8: Function: prep_transfer > 2.5.8.1: Input > A DiskInfo object I am a little confused about this. When doing an install, we create different types of targets. fdisk, swap, pool targets. I am not sure how this only function that takes in a DiskInfo object can create the above targets which we need. Also, it seems like we are missing, zpool, zvol, dump and BE types in terms of target types we need to handle. DiskInfo, it seems to me, only handles the initial fdisk/slice configuration setup. Not zpool attributes, or BE info. Maybe I am not clear on how this will work. Can you clarify? thanks, sarah ***** Sue Sohn wrote: > We have posted the design document for the Text Installer at: > > http://www.opensolaris.org/os/project/caiman/TextInstallerProject/design_doc_v1.4.pdf > > > > Please review and provide comments by COB Tuesday, September 15th. > > Thanks, > Sue > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
