Hi Sarah.
In order to keep it shorter, I have only left in this email the items I
had further comments on.
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.
>> 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.
>> 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?
>
> 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.
>
> 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
>> 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.
>
>> 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.
Thanks,
Jack
>
