Hi Sarah,

Here are my comments/questions...


2.0
Do application-specific core engine classes that are provided for by
sub-projects (for example the Manifest Retrieval class or the Media Creation
class from 5.2 and 5.3 respectively) become part of the engine once
developed, or are they only part of the application?


2.1
Should error reporting be listed as a requirement on the execution engine
as well?


2.2  The Data Collection component

What does "global installation data" include?  Is this only the data that
represents an AI manifest, or a superset of the AI manifest?  ... or is 
the intent
for Data Collection to be used for random data object storage between 
the Core
components?


3.2.1.1

Partition Class / Slice Class
nit - What about entire partitions that are allocated to pools?  The
Partition Class also seems to need a get_inuse() method

FileSystem Class / Dataset Class
This is perhaps another nit, but the relationship of the Dataset Class being
a subclass of the FileSystem class doesn't align with the the ZFS 
definitions
for those objects.  Not all datasets are filesystems, e.g. ZFS Volume 
and a ZFS
snapshots aren't filesystems.

VMEnv Class / Zone Class
WRT the R&R statement in the last paragraph of 3.2.1.1 (first paragraph on
page 14), an assumption here seems to be that the zone content itself always
lives in the same pool as where the zone configuration is found.  That's not
always the case.  Zones (and the VMs represented by the VMEnv Class) are
logical targets, but their translation into physical devices (for target 
discovery)
would seem to be dependent on another logical target -- an installed Solaris
instance (or a BootEnv seems to be the closest object defined).

(Perhaps we need to delineate between logical devices --pools, filesystems,
zfs datasets-- vs. logical targets --solaris instances, zones, VMs-- 
which occupy
logical devices and/or physical devices?)


4.1  Drawing 4.1
Just a clarification question.  From 2.1, "A progress receiver 
(typically the user
interface) implements the following ...", gave me the impression that the ui
Application is what provides the ProgressReceiver methods, is that the case?
If so, that's not very obvious here; but perhaps that's just too much 
detail for
this diagram.



thanks,
-ethan


On 12/01/09 14:18, Sarah Jelinek wrote:
> Hi Caimaniacs,
>
> I know you have been waiting for this bestseller to hit the shelves! :-).
>
> The Caiman team has been working on an updated architecture and we have
> the architecture document ready for review. The opensolaris-caiman
> project architecture page is located here(formerly known as Caiman
> Unified Design):
>
> http://hub.opensolaris.org/bin/view/Project+caiman/CUD
>
> The Caiman architecture document open for review is located here:
>
> http://hub.opensolaris.org/bin/download/Project+caiman/CUD/caimanarchitecture.pdf
>
>
> Please send comments/questions to caiman-discuss by 12/18/09. If you
> need more time please let us know, with the holidays coming up we may
> have to extend the review period.
>
> Thank you for your time.
>
> Regards,
> sarah
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

Reply via email to