Jack Schwartz wrote: > Hi Sarah. > > In order to keep it shorter, I have only left in this email the items I > had further comments on.
Hi Jack, My comments inline... > > On 01/08/10 14:11, Sarah Jelinek wrote: >>> Section 1: >> >>> second to last PP: 1st sentence was confusing: Could the first type >>> of components be described as "... a set of application components >>> that are used to implement higher-level functionality..."? (I assume >>> that installing a set of packages is an example here because this >>> functionality is layered on top of the pkg(5) command itself.) >> >> What we intend to describe by this is that the these components(the >> first type), are very specific to the application that uses them. For >> example, we will have a 'Media Creation' component for the distro >> constructor that is specific to the distro constructor. It isn't about >> higher lever functionality(although that is certainly true), it's >> about it being application specific functionality, that isn't common >> across the Caiman installer apps. If you have suggestions on how to >> describe this in a less confusing way, let me know. > OK, so if I understand correctly, the first set of classes implement > interfaces dealing with a particular functionality, such as media > creation. DC has its version of the class which implements the media > creation interfaces, installers have their versions. I would spell this > out in the document, for example: > "The first set of components define interfaces for specific > functionality which can vary slightly between the applications that use > them. For example, interfaces for installing packages are needed for > both DC and different installers, and will be implemented differently > for each application." > > What threw me was seeing the package installation example as general > since all applications do it, and not focusing on the differences > between how the applications use it. > > The word "Common" in "Common Application Classes" does not make the > first group of classes sound specific. This gets tricky since the > functionality is common but when "zooming in" to the details, the > functionality differs. The first set of classes in the paragraph you noted are the Application Specific classes. The 2nd set is the Common Application classes. The first set of classes are application specific. For example, Media Creation isn't likely something that will be used by any other Caiman installer app. It is pretty specific to DC. The 2nd set of classes, the Common Application classes, are common. So, for example, the Transfer classes will be used by the Caiman applications, including DC, and they won't be different for those applications. To use your example, installing packages is the same for those that need installation of packages. >>> Section 2.2: >>> >>> second bullet: sounds too specific to AI. Leave AI out of it, and >>> just say "manifest". >> >> Actually, it is specific to an AI manifest. The idea is that we want >> to generate an AI manifest so that the user can recreate the install >> they just performed using liveCD or text installer, using AI. So, they >> have an automated, hands-off way to replicate the install. Does this >> make sense? > But DC or some other user of a manifest may want this functionality > too. IMO this shouldn't be functionality offered only by AI. Further, > since this functionality will be offered by a tool used by many > applications, all applications which use it can take advantage of it. Possibly. Here's what we can do. We can dump the cache and produce a manifest for the 'data' part of the installation, which could be used by DC. The 'execution' part, which DC also has(ala finalizer script specification) isn't something that this feature can provide. With the manifest rework I am doing the AI and DC manifests will be in sync, in terms of the 'data' part of the schema. I can remove the AI reference and just say manifest. In general we will dump a manifest, which has to have meaning to a Caiman installer app. >>> 3.2.1.2: >>> >>> VMEnv class: >>> The content of this PP seems tilted toward xVM. What about Virtual >>> Box? LDoms? >> >>> >>> The VMEnv class has no methods. Is the point of the VMEnv class to >>> "mark" an environment as a virtual machine environment? Is it an >>> interface spec which can be combined with other interface specs in >>> this section (e.g. LogicalVolume that defines a lofi-mounted file >>> enveloping the VM environment)? >> >> We don't create VMEnv's as part of our installation, so this class is >> simply a class that allows for discovery of VM's so that the installer >> can show the details of the existing environments. It wasn't my intent >> that it be combined with other interfaces, it is simply a way to >> distinguish the existing environment's targets. > Doesn't a custom VMEnv get created as part of Glenn's virtual machine > constructor? ... or maybe this is a burried implementation detail that > isn't relevant here as it's not part of the VM constructor's final product? Yes, it does, as part of a DC run. That's an interesting point. Since DC will be using the engine, it makes sense it would be using the Target Data classes so I may need to rethink this. Actually, I am sure I need to rethink this. Thank you for pointing this out. I will rework this section. >> However, in responding to you I realized that some of the details of >> the associations for VMEnv's are not specified. I don't intend to >> include VBox(type 2) in this class. > OK... >> >> LDoms are type 1, as is xVM. So, in this case there is a 'storage' >> device mapped to the domain and that is something we need to be able >> to show the associations for. Storage can be zvol, file, or physical >> device. anything that looks like a block device. With Vbox, they >> manage the 'storage' via a file, we can define its location, but it is >> simply a file. > OK, so what you are interested in is the file system which would get > created inside that file (or possibly a lofi-mounted file, for that > matter), not the file itself. Yes, basically that's what I am interested in. >> So, when the 'storage' for a VM is not a physical device, the >> associations will show up via a Zpool class. The file must reside >> somewhere so any storage allocated to the datasets will be shown as >> 'in use' When 'storage' is a physical device we want to show that the >> allocated device is part of a VM. I need to work on this class a bit >> more since it is not complete(as I talk through my response). >> >> Why not type 2 hypervisors? Because they don't matter in terms of >> target discovery, or target instantiation(because we don't create >> them). They are backed by a file, which will be contained in a >> dataset, contained in a pool, so we don't have to manage this >> association knowledge. > OK Except, with the use case you mention above, I need to rethink this. >>> 4.2.2: >>> Drawing 4.3: >> >>> I think that when you look at the columns, the partition loop >>> envelopes the slice loop. (That is, the right most :partition column >>> represents the looping through all partitions, and following that >>> column down, we enter the slice loop for that partition.) This seems >>> correct to me. But the box enveloping the slice loop is outside the >>> box enveloping the partition loop. Shouldn't the slice loop box be >>> inside the partition loop box, much like the partition loop box is >>> inside the disk loop box? >> >> The outermost loop box is for all of 'Target Discovery'. Just to be >> clear. The looping, for slice discovery comes from the 'Partition' >> object. If you look at the diagram, the creation of the Slice object >> happens from a Partition object. It is hard to see, but the intent is >> that a Partition starts discovery for its slices. The loop boxes do >> not have to be overlapping or embedded in each other. The loop box is >> intended to show what the constraint is, discover != NULL, that's it >> really. It's hard to show this with UML. > OK, so now my understanding is that the dotted line starting from > :Partition and leading to the slice loop means to loop through all > slices of a given partition. The slice value is not considered in > whether to loop again, but only (discover != NULL) is. Basically yes. However, if there are no more slices, then discover would be set to NULL. 'discover' is simply the term I put in the UML diagram, but that translates, in this case, to are there any more slices for this partition? If not, stop looping. >>> 4.2.3: >>> Drawing 4.4: >>> >>> Is the reason why there is no instantiate() under the :disk loop >>> because the disk is a physical medium? To me, instantiate() creates >>> an object representation of something (e.g. an object representing a >>> disk), as opposed to the thing itself (e.g. the disk). If this is >>> the correct interpretation, there is a missing instantiate() in the >>> :disk loop. >>> >> >> Yes, basically it's because we don't create a disk target during >> install, we use them, but they are set. The instantiate() method >> takes the populated instance data and creates the corresponding device >> on the system. Probably a bad choice of naming, which is why you are >> confused. I was going to use 'create()' but that seemed wrong as well. >> Any suggestions? > How about create_target() or create_device()? > create_target() is my first choice as it seems clearest. > create_device() follows conventions in this document. I like these better. Let me rework this method name and I will send out an update. Thank you again for taking the time to look at this in such detail. Your comments were great! sarah
