Hi Sarah.
On 01/12/10 10:39, Sarah Jelinek wrote:
>
>
> 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.
OK. I took media creation and turned it into more general "package
installation using pkg". My misunderstanding.
>
> 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.
Yes.
>
>>>> 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.
Yes, this would be a dump of the data in the format of the application's
manifest. This data can then be used later to re-create the same
operation (e.g. installation, creation).
>
> >>> 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.
OK. Seems clearer to say something like "loop through all slices"
instead of "discover != NULL".
<snip>
>
>
> Thank you again for taking the time to look at this in such detail.
> Your comments were great!
Thank you for taking the time to clarify both the document and my
understanding! Much appreciated!
Jack
>
> sarah
