Hi Sarah, Replies inline.
Sarah Jelinek wrote: > 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. With that in mind, I will update the doc to indicate that the libtd_pymod bridge will expose start_td_disk_discover, and register a callback that will fire off an indicator of how much data is available. In keeping with CUE, the data will be accessible via the cache, which will return XML data. InstallationProfile et. al. will be updated to be Text Install private, and use the XML data behind the scenes. > > Same comments for other common functionality, such as setting time and > locale. I'm still not sure where configure_time should live. But yes, it should be in a common area. > >> 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? I see your point. This should be a new ICT that, in the short term, will edit the files on the installed system. In the long term, it will call into the interface that will be provided by networking as part of bug 10307. There is a question of whether we should set up the interface on the live environment, inside the text installer. Initially, we were inclined to do so, and verify that the network parameters "worked." I'm now less sure of what that would entail, given that we're not enabling name services. > >> 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? I will admit that, due to the use of miscellaneous globals and arbitrary nvlist data, it seems that I missed some pieces for calling into TI. liborchestrator calls into ti_create_target 5 times: - fdisk / partition - VTOC - Zpool - ZFS Volumes - BE As you mention, partition and VTOC data is captured. From what I can tell, what's still needed is: zpool name, ZFS dataset info (including name, type and size data), and BE info (including name, zfs data and mountpoint). I will add that data to the Python objects. Is anything else missing? Thanks, Keith > > > 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 > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
