Jan, Jan Damborsky wrote: > 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. Please make sure that the code changes are additions since orchestrator needs to works the same way in the dwarf path. > > 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 Still the design document doesn't say clearly what are the targets created by Slim Install. For example does it create Solaris fdisk partition or assumes that Solaris fdisk partition is created by the user. > * orchestrator invokes transfer module with information about created > target What is the interaction between TI module and transfer module? does the transfer module expects a mounted directory? Where does this information come from? > * ... > > 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 ? You can say slim is supported only on the ZFS environment. > >> >> >> 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. My question is how do you determine whether the disk is a new disk or a disk with data. If the disk has user data, we may destroy it. > > 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. So for October release, does the TI module creates ZFS pools and datasets? > > 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 ? Both fdisk and format are interactive tools. If you call those tools in your install, it will bring up shell to run those tools. It may not conform to the slim GUI and users won't like it. > >> - 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. My comment meant that the real fdisk partition management is done by libspmi libraries and used by both pfinstall and ttinstall. The implementation is not completely in pfinstall. > >> - 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. How will you differentiate no label and unknown label? > >> - 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. I agree with you about libspmi but if it is doing the right thing, please take a look at them first. These functions are written because the tools couldn't satisfy install needs. > > >> >> 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. My feeling that we should not add stuff that is not needed for install. There are ZFS tools that allows creation of non-root ZFS tool. > >> >> 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. Can we split the API in to two different api with one for fdisk and another for ZFS?
- Sundar > >> - 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 >> >> >> >> >> >
