Hi Jean, Dave and Sanjay,
Below are my comments. I actually did not look at others comments so I
may have repeated some. I wanted to look at this without being
influenced by others comments.
thanks,
sarah
******
Page 4:
This sentence:
Solaris is installed in a partionsmarked "Solaris 2".,
should be: in a partition marked...
Page 5:
"The figure above is an example of an FDISK label with an
extended partition. A logical partition has been designated as a Solaris
2 partition.
A VTOC label is used to further subdivide the logical partitions into
slices.
Note: This should be the ¨figure below...¨
Page 7:
"Once a device or set of devices have been discovered, the next phase is to
determine the logical components."
Note: Seems to me that a better wording would be something like:
Once a set of physical devices have been discovered, the next phase is
to discover
the logical devices that are comprised with the physical devices.
The existing wording makes it seem as if the logical devices are
components of the
physical devices, which they are not.
Section 5,Page 7:
The notion of a ZFS dataset residing on top of a pool seems strange to
me. ZFS
datasets live within a pool, not on top of a pool. I get what you are trying
to describe here, but the description of this doesn't seem to fit the design
of the zpool/zfs dataset relationship.
Section 5.1, Page 8:
The decomposition diagrams seem not quite correct. The diagrams should show
zpool at the top, and the decomposition moving downward, since we are trying
to reduce the zpool to its original components, right? These diagrams look
like composition to me.
The simple way you show the zfs decomposition doesn't really work for me. It
doesn't affect the overall design but if we have the diagram we have
for the SVM decomposition we should have something similar for ZFS.
Page 11, Section 6:
General: This section could use a lot more descriptions for the classes,
relationships
and how these are used. I can't really get how this fits, except at a
basic level
of the physical and logical devices, together.
Specific:
"On Solaris, this results in the user selecting a slice or a partition
on a disk to
install the release."
Actually, the user can select a disk, a slice, a partition or a zpool to
install
the release.
Page 12, Section 6.2:
What are HolyPartition and HolySlice objects and what are they used for?
Why do we have a PartitionChildren object?
What is the ShadowList? How is this kept in the DOC and why do the objects
in in the UML diagram on page 13 have to_xml() methods as well.
Basically, I don't
understand where the DiskSliceChildren, etc... come in and how this ends
up as a valid xml document at the end. Can you provide more details on this?
Page 12, Section 6.3, Logical Target Inheritance:
The architecture document indicates that we should have a
LegacyFilesystem class. The
diagram you show on this page has a UFS class which inherits from
PhyAggregate. I
don't know what PhyAggregate is supposed to represent. Can you describe?
If we had other filesystem types, such as PCFS, how would they fit into
this model?
What is a LimitedSliceList class and how is it used?
What about ZVOL's?
We have a SnapshotList class but no Snapshot class.
Page 16, Section 7.2: DOC requirements:
-how/where does the DOC specify the starting point? As a parameter to
the 'execute()'
method or is this something the TD execute() method looks up in the DOC?
What is the discovered_target child node? I don't see mention of it in
the object
models you have presented prior to this section. How does it fit in to
the object
model?
Page 17, Section 8.0, Target instantiation:
Why would we need to have a 'destroy' function? The data specified for
TI should
be complete, in that we either create, use, preserve or remove targets,
but it
isn't a destruction process really, it is a process of creating the target
the way the user/application has specified it.
TI must be able to create pools as well.
Section 8.2:
"The TI module will require the DOC to contain a s"
What is this supposed to say?
What is the discovered_target object in this section? I assume you mean
something
like a 'created_target' object. How does this fit in to the object model for
target devices?
General object model comments:
I don't see the following logical target classes:
Zone
VMEnv
LegacyLogicalVolume
Also, many of the methods defined in the Caiman architecture document are
not shown in your design doc. It may be that they are there, or that you
have
made changes from the architecture but either way we should account for
these. Perhaps
in an appendix or something. If these are private interfaces then fine, but
it isn't clear to me what has been explicitly changed, what is private
and what
is just not shown.
I don't see how the BootEnv class could be used for other versions of
Solaris that
are not Solaris 11. We need the ability to discover these as part of the
s10->s11
coexistence. It may just work, but I note this because it isn't obvious
it will work.
-----------------------------------------------------------------------------------------------------------
On 07/27/10 01:34 PM, jean.mccormack wrote:
Please review the design doc for the Common Object classes/TI/TD
design located at:
http://hub.opensolaris.org/bin/view/Project+caiman/CUE_docs
We'd like to get comments by COB on Tuesday August 3rd.
Thanks,
Jean, Dave, & Sanjay
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
