Hi Sundar, thank you very much for your feedback. Please see my response in line.
Jan Sundar Yamunachari wrote: > jan damborsky wrote: >> Hi all, >> >> preliminary version of design document for Target Instantiation Service >> which is part of Slim Install project has been posted on >> >> http://opensolaris.org/os/project/caiman/files/slim_ti_design-2.pdf >> >> It is the first draft with many issues still pending and many design >> details >> to be determined. Any comments, questions, suggestions are appreciated. >> If possible, please review the document by the COB 9/19/07. >> >> Thank you very much, >> Jan >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> > Jan, > > These are my comments. In general you design assumes lot of changes > in the orchestrator module. For example Orchestrator doesn't talk > about ZFS. Are you planning to update the orchestrator design document > with the changes? You are right that orchestrator would need to be modified, so that target instantiation (TI) might work properly. As you are mentioning above, for Slim, TI will be creating appropriate ZFS structures for handling final Solaris instance. Information about ZFS configuration would need to be provided by orchestrator. For October release, set of attributes describing ZFS structures will be simple and will probably only contain information about ZFS root pool and ZFS file systems to be created. Other modifications which would need to be done to orchestrator relate to the intent not to use pfinstall engine for Slim. In Dwarf orchestrator prepares profile file according to information received from GUI and then invokes pfinstall in order to carry out set of tasks, which for Slim are to be carried out by TI and transfer module. Since TI will be implemented as shared library and will use other approach for describing final target (target will be determined by set of attributes passed as nv list to the TI), orchestrator would need to be modified accordingly. For October release, the information passed from orchestrator to TI will be limited and probably hard wired in orchestrator (slice configuration, name of ZFS root pool, set of ZFS file systems to be created - /, /usr, /opt, ...) and thus not configurable from GUI. I am attaching initial version of TI task list with features are supposed to be delivered for October release and what might be the requirement for March. As soon as it is determined, how and which information would flow between orchestrator and TI, I think I might also update orchestrator design document accordingly. > > Section 1: Assumptions > > - The project assumes that ZFS root/boot is available. Can you add > the information whether it is already available or when it is expected > to be available? The ZFS structures (root pool and file systems) will be created by TI according to information received from orchestrator. In general, I could think about following flow of control: * orchestrator receives information about target from target discovery service * user creates desired target configuration in GUI (limited or not supported for October) and passes it back to the orchestrator * orchestrator passes this information to the target instantiation service which then prepares target accordingly * orchestrator invokes transfer module with information about created target * ... I will add appropriate information to the document. > > - What is a basic environement? (The second bullet in the assumptions) I agree this is not quite good wording. I wanted to say that Slim doesn't address install within zones or XEN environment. What might be the more appropriate term here ? > > > Section 2: > > - What is a Manager Module (MM)? Is it same as TI manager? The name > sounds too generic. Can you change it to refer to the actual > functionality? Yes, MM is the same as TI manager. I will consolidate it to more specific TI manager within document. > > Section 5.1.1: > > - Design is spelled as desifn OK. I have corrected it. > > Section 5.2: > > - Are we planning to support creation of zfs pool across multiple > disks during installation? It is not addressed for October release. I am not sure right now, if we would support it for March. If I have understood correctly, only non-root ZFS pool can be spread across several disks. As far as root pool is concerned, I think that support of mirror configuration might be taken into account. > - What is meant by "It is possible to install on unlabeled disks". > How do we determine whether the disk doesn't have a label or it has a > label we don't understand? I was thinking about the case, where sparc is shipped with unlabeled disk. In this case it would be necessary to label disk before read_vtoc()/write_vtoc() interfaces could be used for creating VTOC structure. I will clarify this point in document. > - I don't understand the third bullet "There should be possibility > of utilizing unallocated disk space when creating new Solaris > partition". Do you mean there will be an interface in MM to specify a > special keyword to use all free space? I meant to say that TI will have to provide following features: * creating new Solaris partition within unallocated disk space, when there is no Solaris partition available (not for October) * using existing Solaris partition For October release, it is supposed that there would be Solaris partition already created before TI is invoked. User will be asked to prepare one before installation is invoked. It is still not determined for now, how set of attributes describing the target partition configuration will look like. Probably the main issue here is to choose the right level of abstraction. For example, the orchestrator might pass to TI name of the target device and complete partition table to be created. On the other hand, it might also say to TI something like "Create at least 20GB Solaris partition and then let me know where and how big it was actually created". We would need to find appropriate balance here for March. > - CLI tools fdisk and and Format can't be used from GUI. Why these > CLI tools are mentioned here? I have meant that TI would use these CLI for creating appropriate label/partition table on disks. If I have understood your assertion correctly, is that mean that if TI is implemented as shared library utilized indirectly by GUI via orchestrator, it is not possible to consume these CLI by TI library ? > - pfinstall and ttinstall manages fdisk partitions using the > libspmi libraries. Since pfinstall is not considered to be used for Slim TI would need to implement another approach for managing fdisk partitions. > - I am not sure whether it is a good idea to create a label. We may > destroy the user data. Label should only be created when unlabeled disk is recognized (for sparc). I will clarify this point. > - Are you planning to use fdisk tool to create/modify fdisk table? > Why can't use the existing libspmi interfaces? Originally I was planning to use fdisk utility for this. But this assumption might probably change, since we will probably not deal with fdisk partitions in TI for October release and for March it is now discussed using new interfaces which could be available at that time (for example libfdisk library might be one of candidates). In accordance with the long term goal, we would like to decrease utilizing existing spmi interfaces, so that using of spmi libraries might be completely avoided in future. > > Section 5.3.1: > > - Why install needs to create non-root ZFS pool? This is not requirement for October, since all bits will be installed within one root pool. But based on assumption that root pool can't be striped across several slices, it might be useful to have possibility to define non-root pool which might for example utilize remaining devices not consumed by root pool. > > Section 7: > > - If I want to use the existing target (fdisk partition), do have > to use ti_target_create() from the orchestrator? Yes. If fdisk configuration is suitable (that would mean there is existing Solaris partition available - this assumption is taken for October release) orchestrator would still need to call ti_target_create() with appropriate set of attributes passed as nv list. In this case, attributes wouldn't contain information about fdisk configuration, but would be expected to contain information about slice (VTOC) as well as ZFS configuration. > - What about deleting a partition? This feature is not supported for October, but will probably be required for March. It is not determined for now, how this information will be passed from orchestrator to TI. > > That is all for now. Thank you very much. > > - Sundar > > > > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: tasklist.txt URL: <http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20070914/75495219/attachment.txt>
