Hi Sarah, Sarah Jelinek wrote: > Hi Keith, > > Apologies for the delay in responding.. my comments inline. > > >> 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. > > > This sound good. I am not clear how we could register a callback in > the python bridge? How would this work?
See libtransfer and libtransfer_pymod for an example; specifically, tmod_logprogress and tmod_set_callback in libtransfer.c. > >>> >>> 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. > > It will be, and I am working with Jean on this. > >> >>> >>>> 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. > > > Ok. > >> 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. > > You are not doing any nameservice setup? I thought that was on your > plate. Maybe I misunderstood. It seems there was a bit of confusion at one point. Initially there were no plans for name services; now, DNS is on the table (but no other 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? > > I think that's it. Excellent, thanks! - Keith > > > thanks, > sarah > ***** >> >> >> 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
