Hi Sarah, Great job ! Please see my comments/questions below. I haven't gone through the other comments, so please feel free to redirect me to the appropriate thread where applicable :-)
Thank you, Jan 1. Introduction and Overview ---------------------------- In architecturally significant points, I am wondering if Distro Constructor should be mentioned as well. In next to last paragraph, it is explained that "The architecture of the New Solaris Install installation suite is decomposed into two types of components" I can see that there is an example for Common Application Classes (installing a set of packages), but not for Core Engine Classes. I might recommend to add example for Core Engine Classes to help people envision what it covers. Also from that paragraph it seems that those two Classes are discjunctive sets, but at the beginning of Chapter 2 it seems that Core Engine Classes are superset of Common Application Classes. I think it might be confusing and thus might need to be more clarified. 2.2 Data Collection ------------------- "Provide the ability to translate global installation data into valid Automated Installer (AI) manifest" Should then this component be also in charge of the reversed transformation (populating global installation data from AI manifest) ? 3. Common Application Classes ----------------------------- Should ICT be also included ? 3.1 manifest parser ------------------- Only syntactic validation is mentioned - are we going to consider semantic validation of the manifest as well ? 3.2 Target Discovery -------------------- * Partitions, both FAT and GPT -> * Partitions, both FDISK and GPT Just curious, what will be the purpose of discovering XEN DomU instances ? See Section 3.2 - reference should be perhaps updated, section 3.2 is the current one. 3.2.1.1 Physical Device Classes ------------------------------- Why do we need set_*() methods for Target Discovery ? It seems those would be used by Target Discovery itself to populate data structures ? 3.2.1.2 Logical Device Classes ------------------------------ What LogicalVolume represents ? 3.3 Target instantiation ------------------------ * I think that support for GPT(EFI) should be added 5.4 installadm(1M) Image Management ----------------------------------- Dave recently put together proposal for this part - will this be embedded in CUD design doc or rather handled separately ? If latter is the case, then I might recommend just to reference it in CUD, since some points might be obsoleted by Dave's proposal (e.g. bullet 1). On 12/ 1/09 11: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
