Sarah,
This is a well-written document. It gives a complete picture of all
installation tools and modules.
Page 2:
- The links to opensolaris.org documents (1,2 and 3) doesn't work.
- The differences between 2 (Installation from pre-packaged media,
such as a CD, DVD, or USB flash memory stick) and 4 (Booting of the
installation environment from media such as CD, DVD, or USB flash
memory) are not clear. What do you mean by installation in this case?
- I don't understand 9 (Sufficient system configuration support to
achieve a useful, running installation on the first boot). What is meant
by running installation on the first boot?
Page 3:
- The words "Install installation" looks redundant in "New Solaris
Install installation suite"
- Can you give an example for "a set of components that provide
common behaviors usable by applications" similar to the example for "a
set of components that are used to implement specific application
functionality"?
Page 4:
- What is an "installation sequence?" (Section 2.1)
Page 5:
- get_progress_estimate(): retrieves an estimate of the time
required to execute the checkpoint
My understanding of the checkpoint is that it is a milestone or
endpoint. How can you estimate with out a starting point?
- For progress reporting, the progress receiver gets the updated
progress from update() method. Who will report progress? (which modules
provide progress data and what is the interface?)
- Section 2.2 second bullet "Provide the ability to translate global
installation data into a valid Automated Installer (AI) Manifest"
What is the reason behind this requirement? How does the DC fit
in to the picture? How do you translate DC data in AI manifest? Also if
the user has installed from a media (not using a repo), will a default
repo used as the repo in the AI manifest?
Page 6:
- Why data being converted to xml? Why the architecture document
cares about data format?
- section 2.3 "logging and error reporting"
Is there any plan to support multiple logging levels?
Page 7:
- Why the architecture document have details about specific
implementation like "Python logging?"
Page 9:
- What about an interface to enumerate the disks on the system?
- There are two "get_assoc_slices()". One should be "set_assoc_slices()"
Page 10:
- I am confused whether the partition class refer to all partitions
or a single partition? It looks like it refers to a single partition.
- Do you need methods that provide information about the partitions
like type, size, id etc?
- Why slice class needs associated parts? All slices either
associated with a single partition or single disk.
- I have same questions for slices I listed for partitions
- What are the flags in slice class?
Page 14:
- What about GPT in target instantiation?
Page 15:
- Does the TD, TI and Transfer need methods to provide progress
reporting?
Page 32:
- I don't think that the server side (installadm) fits in to the
architecture. Since we have plans to run the server side setup on
systems running different operating systems, We need to have a different
design to fit those needs.
Thanks,
Sundar
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
