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
This is great Sarah! I learned a lot reading it I find the UML Sequence
Diagrams especially helpful!
My comments below. Many of which are simply questions.
Joe
- - -
Question/Issue:
---------------
1.5. Booting of the installation environment from a network server.
What does this mean? How is it different from 1.3?
Suggestion:
-----------
Perhaps it would be valuable to list the application names with
the bulleted list on page 2->3
Question/Issue:
---------------
"An interactive installation application with a text user interface,
targeted primarily at server systems"
I thought we wanted to use IPS for text installer because canned
bits which could be CPIOed off the media didn't address server
system user requirements.
Do we need to communicate TI will be CPIO based?
Question/Issue:
---------------
"An automated installation application that installs a system without user
intervention using a pre-configured or computed configuration"
"A tool to generate a replication image of an installed system"
What do these referring to, VMC or R&R ?
Question:
---------
p.3
Core ENgine Classes
Do we need a IPC Core Engine Class? Or will the data store act as an
IPC? I don't currently know of a need for a CoreEngine IPC but I can
imagine it might turn out to be valuable.
Question/Issue:
---------------
2.1 Execution
Would it make sense to add "Registration / Configure to the bullet
list top of p. 4?
Question/Issue:
---------------
p.4
- Report progress to the installation application during execution
of the installation sequence
- Manage logging of the installation sequence
Should these be under secton 2.3 instead of 2.1
Question/Issue:
---------------
p.4
- add_logger(): configures a logger to be used during execution
Should we add "change log levels"
I could see this being valuable for diaging failures.
e.g.
CheckPoint failed.
We could change log level and restart at CP 5
Question/Issue:
---------------
- add_logger(): configures a logger to be used during execution
Should this be under secton 2.3 instead of 2.1
Suggestion:
---------------
p.5
2.2 Data Collection
I found this confusing:
- Provide stable, extensible management, storage,
I had to read that sentance a couple of times before the meaning was
clear. Maybe it's just me. ;)
I thing removing "extensible management," might make it read better.
- Provide stable, extensible management, storage,
Question/Issue:
---------------
p.5
- Provide the ability to translate global installation data into a
valid Automated Installer (AI) Manifest.
What does this mean? From where ? Does it mean from an already
installed system for replication?
Question/Issue:
---------------
p.5
All Common Application objects, as well as New Solaris Installer
applications will have read-write
I think it may be valuable to provide a means to limit write access...
Just thinking it could come in handy for future applications.
Question/Issue:
---------------
p. 6
- to_xml()
Through out the document XML is mentioned. Isn't that an implementation
detail that could change? Pehaps XML may be replaced by something else
in the future.
Would
- to_store() or something be more generic and valuable?
Also would a from_xml() provide pulling from xml to a variable?
Question/Issue:
---------------
p.6
2.3 Logging and Error Reporting
Should this be: "Logging, Error Reporting and Progress reporting" ?
Question/Issue:
---------------
p.6
2.3 Logging and Error Reporting
open(), log_message(), close()
I think better names might make the code more readable by indicating
these are logger APIs.
e.g.
log_open(), log_message(), log_close()
Question/Issue:
---------------
How will logging be made available to external components? For example
VMC could benefit from logging being made available from the bootable
AI running in a Virtual Box Client to VMC running on the VBox host.
Suggestion:
-----------
I think a checkpoint should implement it's own clean up. Each checkpoint
should know what and how to cleanup after itself.
I think the Execution Classes method: cleanup_checkpoints() should invoke
the checkpoints cleanup entry point.
Maybe the Execution Class could contain a register_cleanup_checkpoint()
method.
Question/Issue:
---------------
Should this be changed from:
To enable extensibility and ease of translation of data to a common
data storage format, the "data" classes defined in Section 3 must
provide the following method:
To:
To enable extensibility and ease of translation of data to a common
data storage format, the "application" classes defined in Section 3
must provide the following method:
Question/Issue:
---------------
p.7
3.1 Manifest Parser
parse()
would an import() or store() also be neede are is this functionality
part of what parse() will do? Is there any reason it might be valuable
to make this 2 steps: validate and import?
Question/Issue:
---------------
p.7
3.1 Manifest Parser
The requirement defined for this component is:
- Must provide syntactic validation of user-provided manifests
Should the requirement also include the following?
- Storing the manifest data in storage cache utilizing the Data
Collection Class.
Question/Issue:
---------------
p.8
3.2 Target Discovery
The bullet item list contains both:
- Partitions, both FAT and GPT
- Slices
and again on p.9
- Partition
- Slice
What's the difference between a partition and a slice?
Question:
---------
p.8
- Virtual Machines hosted by a Solaris xVM Dom0
What's this?
Question/Issue:
---------------
p.9
to_xml()
Again I think to_store(), or the like, might be better than "xml"
which is an implementation that could change.
Question/Issue:
---------------
p.9
DiskClass
Chould a get_dev_path() be valuable? e.g. something would which would
return /dev/dsk/xyx be valuable?
Question/Issue:
---------------
p.11
ZpoolClass
Do we need to support more of what zpool(1m) provides?
e.g. create, iostat, remove, status
Question:
---------
p.12
LogicalVolume Class
- set_size()
Won't we need to get logical volume info/data ?
Question/Issue:
---------------
p.13
Dataset Class
Do we need to support more of what zfs(1m) provides?
Question/Issue:
---------------
p.13
Zone Class
Do we need to support more of what zoneadm(1m) provides?
Question/Issue:
---------------
p.14
3.4 Transfer
- SVR4 packages
Why SVR4?
Should we account for support of virtual import of VMC output?
Question:
---------
p.15
- data archive
What's data archive for?
Question/Issue:
---------------
p.16
Shouldn't the ManifestParse have lines directly down to the components,
e.g. Transfer, TD & TI?
Or is Checkpointing going to providing the data from the manifest?
Question:
---------
p.16
What is the flow of data collection? Is it only through the
ExecutionEngine?
Comment:
--------
P.18->23
These diagrams are great! Very helpful.
+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=
+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=
Below are comments I have from an older version of the document:
+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=
+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=+-=
3.2.5 Assumptions
-----------------
- We will not have one monolithic library that provides a single consumer
interface.
- Not having one monolithic library is a good idea
- I think we should strive to have a common API standard accross
Caiman engine components.
- Consumers must maintain the state of their specific application data.
- I think the consumer should maintain state but do so by using
a common engine interface. We should supply a state holding module.
- We will utilize the existing DC finalizer engine technology as a starting
point for the installation driver engine. It will be re-designed to
accommodate a wider consumer audience.
- I think leveraging the Finalizer engine is a good idea, however
fundamental changes would be needed.
e.g.
- Passing run time gathered arguments to finalizer scripts
- Being able to invoke finalizer scripts from different modules.
- Changing out the liborchestrator code completely will happen over time.
- I think supporting a phased in approach of the replacement of the
libraries with the new modular components may present excessive
overhead. I think it would be benificial if the new engine framework
were mostly in place. Then once we have the engine foundation we could
migrate the addoptoin of the new engine. Leaving some on the old model
as we work the migration schedule.
3.3.2 Test Environments
-----------------------
- A well defined API to modular components will facilitate
easier testing. I think testing of all of the different installers
in all of the supported environments may not be as necessary if
the supporting common modular components can be effectively
exercised in each test environment.
4. Functional Description
-------------------------
- The description of using callbacks in section 4. Functional
Description may not be accurate as that approach would be associated
with a functional "C" solution. If we were to consider an OOD approach
"callbacks" may not be correct.
- What's the "Data collection object"? Is it logging?
- I understand that the new Caiman Engine needs to provide the
functionality of what is currently in libO however I think we should
design what is required independent of libO and how libO is implemented
today.
- We should design a consistent method of managing and passing consumer
data between the engine modules. The parser/validation module describes
some of how this will be done for user data from XML. I think we should
consider having a user data gathering engine module that is independent
of were the data comes from XML or GUI. Some data will also need to be
gathered and acted on between engine modules. e.g. Target discover finds
devices, the user selects which to install to, then target instanc.
works on that device... A single common module should be used to manage
gathering and passing this data. This will contribute to extensibility.
OK I see: This is the Data Collection Object
5.1 Consumers.
--------------
I see DC and perhaps R&R the same as LiveCD, TextI, AIC and VMC.
boomvang >
