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? >> >> 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. >> >>> 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. 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
