Hi Sarah,
On 01/13/10 08:32 PM, Sarah Jelinek wrote: > 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 >> >> > >> >> 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. I see - thank you for clarifying 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. ok. > >> 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. I agree some of ICT tasks are media specific, but I think there is a set of post installation stuff which is to be done regardless of mechanism used for the installation, e.g. * setting hostid * activating Solaris partition * installing grub bootloader * setting Sparc eeprom properies (e.g. boot-device) * transferring log files to the target ... How is it envisioned to accomplish those kind of tasks in CUD ? > 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. ok. > >> >> >> 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. I see - understood. > >> 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. I see. I was just curious if there is a special purpose for them. > > > >> 3.2.1.2 Logical Device Classes >> ------------------------------ >> >> What LogicalVolume represents ? >> > > SVM, VxVM, ZVOL logical volume types. I got it now - thank you. Thank you for the clarification ! Jan
