Hi Sarah, Here are my comments on the document.
General: --------------- - Question: throughout the document, you choose "class" to refer to the different pieces of the New Solaris Installation suite. Why is "class" chosen? I generally see "class" being used in the object oriented programming context. Is it implied that our implementation of the suite must be done in a language that supports OO? Would it be more general to refer to the different pieces as "module" or "component"? - In various parts of the document, there's mention about certain python features being used, such as using the python logging module for the engine. Would it make sense to spell out Python as the language that will be used? Specific comments: ------------------------------- Section 1: - The list of of "architecturally significant points" did not include any requirement for being able to create customization images (DC), and the ability to easily upgrade (snap). Is that intentional? Section 2: - This section mentioned that the engine offers functionality to pause or stop the installation at each checkpoint, and to resume at those checkpoints. Currently, DC provides similar functionality if the "installation target" is on a ZFS dataset. In order to provide these functionalities, do we also require the installation target to be a ZFS dataset? Section 2.1, 2nd paragraph: - Question: Can checkpoints interact with the user? If so, does the engine need to coordinate that? If not, please add something in this paragraph to clarify. - This description mentions that the execution engine automatically computes and reports progress as checkpoints are executed. I wonder how realistic it is to report useful overall progress? I suppose each checkpoint can specify a "weight" for themselves indicating whether it is a long checkpoint or short one. Then, the engine can average it out somehow, and assign a weight. But all these will be guesses, not sure how accurate can be overall progress be reported. Section 2.1, the list of methods ExecutionEngine need to provide: - I think it is missing list_checkpoints() or get_checkpoints() so applications would know what value to use when they want to pause/stop/resume. Section 2.1, the list of methods a checkpoint must implement is missing the following: - stop(): this is needed to support cancel() in the engine - percent_completed(): this is useful for progress reporting for long running checkpoints. Section 2.2, second bullet in the beginning: - Why just translate installation data into valid AI manifest? It would be more general to translate it into any manifest. Other installer might be able to accept manifests as input in the future. Section 2.2, the methods provided by the DataCollection class: - clear_cache() and create_cache(), there's no description. I couldn't figure out how they will be used based on the name. Section 3.1, 2nd paragraph: - Do you mean "semantic validation" of user-provided manifests? Section 3.2, the list of objects Target Discovery need to discover: -" Installed instances of other operating systems....", what about existing instances of OpenSolaris? Section 3.2.1: - This whole section talks about the different classes that target discovery needs to support and the interfaces/methods these classes are required to implement. Target discovery is supposed to be a "read" operation, but many of these classes have methods for "write" operations such as set_xxxxx(), snapshot(), clone(), or other functions for implementing a functionality, such as the send()/receive() methods in the Dataset class. I think it is very confusing to have the description for all these in the section for Target discovery. Why not have a completely new section that just talks about all the classes and all the methods it requires, and perhaps talk about what functionality these methods can provide. Section 3.2.1.1, description of the required methods for Partition class and Slice Class - I think you also need get_assoc_disk() and set_assoc_disk() in those 2 classes so it can associate itself back to the disk that contains these partitions/slices. Section 4.1, New Solaris Install UML diagram - Question: does ProgressReciver, DataCollection and Logger all need to talk to the checkpoints, because it is the check points that will generate the "data" for those classes? Or is it true that all the "data" from the checkpoint classes will be reported to the engine, and the engine will dispatch them to the 3 classes as appropriate? - InstallApp needs an arrow to the DataCollection class also, because previous section in the doc talks about DataCollection is instantiated by the app, and the app can access/modify the data outside of the engine. - Question: will the app be able to use the logger too? To log messages/errors? If so, need an arrow. - Should the arrow from InstallApp to ExecutionEngine be bi-directional? Since InstallApp will be getting progress/errors from engine? - Under "FileSystem", only Dataset is listed, what about UFS file systems? Section 4 and Section 5 general comment: - The engine is supposed to provide the ability to pause/stop/resume. It would be useful to have a UML diagram or use case to illustrate how that can be done. Section 5.1, item 4, instance configuration: - You mentioned that this checkpoint will reverse media-specific customizations and apply system configuration options selected by the user. I think that system configuration options, and transferring of the log file are common things that all installers need to do, and most of the code can probably be shared among installers. So, it might be useful for it to be it's own checkpoint class. Reversing of media-specific customization should be in a separate checkpoint class because it is very specific to how the media is constructed. Section 5.3, first paragraph, 2nd sectence: - ..... a manifest is used to drive the installation process.... I think "construction process" sounds better than "installation process" Section 5.3, step 2: - .... create the ZFS datasets required for the construction process. Currently, both UFS and ZFS are supported by DC. Does this imply that we will no longer support UFS? Thanks, --Karen On 12/ 1/09 02:18 PM, Sarah Jelinek wrote: > Hi Caimaniacs, > > I know you have been waiting for this bestseller to hit the shelves! :-). > > The Caiman team has been working on an updated architecture and we > have the architecture document ready for review. The > opensolaris-caiman project architecture page is located here(formerly > known as Caiman Unified Design): > > http://hub.opensolaris.org/bin/view/Project+caiman/CUD > > The Caiman architecture document open for review is located here: > > http://hub.opensolaris.org/bin/download/Project+caiman/CUD/caimanarchitecture.pdf > > > > Please send comments/questions to caiman-discuss by 12/18/09. If you > need more time please let us know, with the holidays coming up we may > have to extend the review period. > > Thank you for your time. > > Regards, > sarah > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
