Hi Jan, Thank you for the review. My comments inline...
> 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. Karen mentioned this as well. I do think that we should mention this in this section so I will add something about it. > > 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. I will add some text describing this. > > 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. No, the Core Engine classes are not a superset of the Common Application classes. Actually, there are three sets of class types: -Core Engine -Common Application -Application Specific(which are not detailed in this document) If this is unclear, I will look at rewording this. > > 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) ? > We do this with the ManifestParser which will then store the data in Data Collection. So, no, I don't think we need to have this called out as part of DataCollection. > 3. Common Application Classes > ----------------------------- > > Should ICT be also included ? > That's a good question. I am surprised nobody else has asked. In general, ICT is pretty specific to the media we are using for installation. And, with system configuration changes(which you are working on!), it isn't likely those would be part of ICT any longer. In the long term we want ICT to be more in sync with system functionality, as opposed to the special things we do today. So, for example, we can use IPS packages to set the locale for a system. > 3.1 manifest parser > ------------------- > > Only syntactic validation is mentioned - are we going to > consider semantic validation of the manifest as well ? Yes, I think we will consider this. It seems to me that semantic validation should be a different class though, which is why I didn't include it in this document at this time. > > > 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 ? In general, for "in use" data. In particular, when a xVM DomU has a real device as its backing store. > See Section 3.2 - reference should be perhaps updated, section 3.2 > is the current one. > Fixed. > 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 ? These are not strictly required, as it is internal to Caiman, but I like having setter and getter pairs. I have no real heartburn if we don't use the setters though. > 3.2.1.2 Logical Device Classes > ------------------------------ > > What LogicalVolume represents ? > SVM, VxVM, ZVOL logical volume types. > 3.3 Target instantiation > ------------------------ > > * I think that support for GPT(EFI) should be added Ok, will add. > 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). It will be referenced and not likely a part of the architecture. I need to finish looking at Dave's proposal and talk with him about this. But, expect change in this area. Thanks again for the review! sarah **** > > > > > 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 >
