On 12/01/09 14:18, 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
Hi Sarah, Here are my comments. 1.0 Does the distinction between 2,3 and 4,5 mean that one should be able to boot from one type of environment (network, media) and install from another? For 10, I assume you mean the first boot after the installation is complete? If so, adding those words would make it clearer. The term "this project" or "the project" is used in various places (first referenced towards the bottom of p2). What does that term mean wrt this document? Everything under the Caiman umbrella? Just the implementation of the architecture (core engine and common app classes)? 2.1 "The engine is capable of beginning execution at the next unreached checkpoint". So if one has reached and stopped at checkpoint 1, they can continue from checkpoint 2?? remove_logger: from execution->from use during execution Similar for remove_progress_receiver 2.2 o to_xml(): why did you choose xml? what else was considered? o retrieve_data(): (nit) methods->method o dump_cache(), "contained in the cache in an AI manifest format". Maybe add a reference or footnote here for the reader who doesn't know what this format is? 2.3 Is the implementation of the architecture assumed to be in Python? This section refers to Python Logging module)? If so, perhaps you should explicitly state that up front somewhere. 3 Mentions AI and DC. Should there be references here? 3.1 o add comma after: "After parsing and validating the manifest" o under parse(): will do-> does 3.2 o Second paragraph, maybe add "in the case of x86" before disk partitions o (nit) passed in to the objects -> passed in to the object's o The See section 3.2 should reference 3.2.1.1 and 3.2.1.2, otherwise points to itself. o Not clear to me why the seed is needed? 3.2.1.1 o Disk Class - there are two get_assoc_slices(). One should be a set_assoc_slices(). o Partition Class - should mention x86 only o Slice Class, what does get_flags do? What kind of flags? Maybe change name to be more descriptive? 3.2.1.2 o Logical devices - It seems odd that there is an instantiate method under TD. There are also several set methods which may fall into the same category. Do these classes have methods for both TD and TI? If so, the document should be more clear on that point. o Dataset Class - represents a ZFS datasets -> represents a ZFS dataset 4.1 You point to the secure wiki for a detailed class diagram. Since this will be an open document, shouldn't the class digram be moved to osol so external users can see it? 4.2.1 I am seeing: "The following diagram Error: Reference source not found, broken into multiple...". 4.2.2 The 4.2 in "Drawing 4.2 shows the sequence of Target Discovery" should be 4.3 Thanks, Sue
